我聽說Google Web Toolkit對於超過5個頁面和通用佈局的網站並不是那麼好。真的嗎?我們至少有100個子頁面和CSS中定義的通用佈局。今天正在使用PHP,但我們將轉向Java MVC或GWT。我們使用som jQuery AJAX和jqGrid等其他jQuery組件。我們也有一些.swf電影和融合圖表。選擇Spring與GWT結合是一個不錯的選擇,還是Spring MVC和jQuery庫是我們更好的選擇?適用於大規模應用程序的GWT
回答
我們的企業級應用程序利用了兩者,我們對結果非常滿意。 GWT是一個強大的工具包,可將開發時間縮短數個數量級。也就是說,GWT要麼處理得不好,要麼只是普通不適合(這也沒關係......這就是Spring MVC住在附近的原因)。我們有GWT-RPC直接打擊Spring服務,它的工作非常好。
雖然我們的項目是一個真正的web應用程序,而不是一個網站。我們使用跨所有「頁面」的統一設計(使用DockLayoutPanel
並更換center
使這非常簡單)。
IMO,誰告訴你,GWT不利於在衆多的「頁面」一貫的設計是堅果...
我認爲,任何斷言GWT(或任何其他方法)的訂單降低開發時間Frederic Brooks在肩墊和Jan Hammer的合成器很時尚的時候已經被揭穿了:http://en.wikipedia.org/wiki/No_Silver_Bullet。
但是,嚴重的是,如果你是一家PHP網店,轉向100%Java將是一筆巨大的投資,不容小覷。
我不同意GWT降低開發時間被布魯克斯揭穿。他的評論是「無論是技術還是管理技術都沒有單一的發展,它本身承諾10年內在生產力,可靠性和簡單性方面甚至會有一個數量級的提高。」他說,在1989年,說*在十年內*不會有這樣的發展。這已經超過二十年了,因此他的陳述是真實的,並且* GWT提供了他所說的不會發生的事情。 – 2012-04-04 12:59:24
我相信他的話意味着,在廣泛採用後的十年內,沒有任何一項技術可以使生產率提高10倍;不是人類的聰明才智會在10年後突然發生巨大的飛躍。技術的組合可能會訣竅。但是,GWT本身*真的使你的工作效率提高了十倍?我不是說它不能。我愛GWT,但它不會創造奇蹟。 – 2012-04-04 13:40:12
奇蹟?沒有。生產力提高了1倍以上,是的。如果沒有其他問題,我花費了100%的時間*製作特殊代碼來適應平臺/瀏覽器的特性。 GWT通過創建多個排列來處理這個問題,每個(統計上顯着的)瀏覽器都有一個排列,從而有效地消除了計劃和反應不同瀏覽器對同一代碼作出反應的時間。 – 2012-04-09 15:37:58
根據我對GWT的經驗,我唯一不好的經歷是由於很多排列組合而導致的GWT編譯速度緩慢。我們的應用程序有超過20種語言可供支持,其中6種瀏覽器的特定結果乘以120個排列,這被證明具有可怕的性能。
但是這不是一個真正的錯誤問題,因爲您將主要使用開發模式和即時代碼更新,並且您可以使用減少瀏覽器和語言集的特殊編譯單元(即使是一種語言和一種瀏覽器= >如果你願意的話可以有一個排列)。
所以在我的情況下,使用Jenkins我們每晚都做大生成目標完整構建,部署在QA平臺上,以便QA團隊測試每種瀏覽器語言組合。在每次提交時,都會在開發驗證平臺上部署一個簡化版本(在我們的例子中爲1個瀏覽器和2種語言)。
對於大型應用程序,GWT絕對是一款絕佳的工具。 ;)
GWT超級開發模式每次刷新的時間縮短到4-6次。相當易於管理。 – 2014-03-12 17:23:47
現在不是這樣。之前的GWT版本確實存在一些可擴展性方面的問題(例如IE中的JS代碼大小問題 - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440),但是由於GWT 2.0在這裏沒有限制。
此外,最新的GWT版本支持將項目拆分爲可在需要時動態加載的部件的功能。請參閱https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting瞭解它是如何工作的。
還要考慮到,由於Spring是Java,因此您可以在服務器端和客戶端之間共享類。 Plus Java在IDE中提供了非常好的支持 - 所有類型的重構都將爲您提供(如果您使用jQuery,它不會很方便)。
所以Spring + GWT看起來更可取的選擇。
GWT不是從頭開始構建任何webapp的通用框架。當你在客戶端有很多複雜的邏輯(圖像編輯,實時協作,圖表繪製,遊戲,複雜的報表生成等)時,它非常有用。但所有這些都可以在沒有GWT的情況下完成。 GWT時才能使用:
- 您的團隊不喜歡/不喜歡JS(並且是無法建立與JS沒有什麼複雜的,僅僅是因爲他們憎恨JS)
- 你的團隊是相當與Java
- 經歷你團隊明白這一切的瀏覽器相關的東西是如何工作的(HTTP,JS,DOM和CSS等)
- 在這個項目中有將在客戶端上運行許多邏輯
我見過不少幾bi g完全用GWT構建的項目。其中一些人不應該使用GWT,因爲他們沒有理由以這種方式使用它。對於大多數項目來說,僅對部分應用程序使用GWT就足夠了。
選擇取決於你的團隊和你正在做的項目。如果你的團隊不能真正看到GWT爲項目帶來的好處,那麼你就不應該使用GWT。
+1不明白爲什麼這是downvoted。 – helpermethod 2012-04-05 07:34:21
- 1. 與GWT的大規模應用程序
- 2. React vs GWT適用於大型Web應用程序
- 3. Morfik - 適用於中等規模的Web企業應用程序
- 4. 什麼技術用於大規模的移動應用程序
- 5. backbone.js適用於大型應用程序
- 6. 關於大規模Web應用程序的研究生課程
- 7. 適用於大規模應用的PHP框架
- 8. 適用於大型應用程序的UML建模工具
- 9. 大規模EXT JS應用程序
- 10. 適用於GWT應用程序的Google +1針對
- 11. JDBC驅動程序不適用於GWT?
- 12. 禁用適用於通用Windows應用程序的應用程序大小
- 13. GWT設計師:是否僅適用於桌面應用程序?
- 14. 適用於asp.net-mvc應用程序的良好規則引擎
- 15. 官方規範和模式適用於Enterprise .net應用程序的Microsoft文檔?
- 16. 適用於多模塊Web應用程序的設計模式
- 17. 規則適用於從iOS應用程序鏈接到iTunes
- 18. Nginx重定向規則不適用於節點應用程序
- 19. Gwt:基於菜單的應用程序
- 20. 適用於中型應用程序的Asp.Net MVC應用程序設計模式
- 21. 使用DDD與Python的大規模服務器應用程序?
- 22. 如何處理GWT上的大型多模塊應用程序
- 23. 適用於移動應用程序的LightSwitch HTML應用程序
- 24. 適用於iPad的Silverlight應用程序
- 25. 適用於Mac的Winform應用程序
- 26. 適用於Web應用程序的Bottle.py
- 27. 適用於Facebook的Android應用程序
- 28. Phonegap:適用於iOS4的應用程序
- 29. 適用於Android的OCR應用程序
- 30. 適用於iPhone的Flex應用程序
你從哪裏聽說GWT不適合超過5頁和共同佈局的_web網站?此外,GWT不適用於web _sites_,但適用於web _apps_,如果這可以幫助您做出選擇。 – 2012-04-04 10:40:00