Java Web 架構的“甜點”

來源:互聯網
上載者:User
web 這是一篇很有趣的文檔,所以摘要一下,其實類似閱讀筆記,好像是3/25發布的:
不知怎麼翻譯Sweet Spots,難道翻譯為甜處、甜頭、蜜點、蜜穴?

本文基於對以下人的採訪(最後兩位的看法獨到還是自己看吧!):
JSF             Jacob Hookom
RIFE            Geert Bevin
Seam            Gavin King
Spring MVC      Rob Harrop
Spring Web Flow Rob Harrop and Keith Donald
Stripes         Tim Fennell
Struts Action 1 Don Brown
Tapestry        Howard Lewis Ship
Trails          Chris Nelson
WebWork         Patrick Lightbody
Wicket          Eelco Hillenius


JSF(Jacob Hookom)

1、你認為你的framework的"甜點"在哪裡?他最適合哪種類型的項目?
當你希望瀏覽器程式像傳統型程式一樣工作的時候,你可以遵循標準並獲得大量第三方支援。它致力於降低複雜度。它允許你不與view和特定的action、參數傳遞、狀態傳遞、渲染打交道就可以進行高品質的開發,不管是否使用工具。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
它不適合大規模的、唯讀(其實指讀為主)的網站。在這種情況推薦Struts,因為知識庫豐富(應該指文檔和使用者群)。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
Seam:
優點:非常簡單直接
缺點:對於大項目過於簡單;沒有模組化開發的好例子
Struts:
優點:巨大的文檔和使用者群;跟著它沒錯
缺點:狀態/行為的分離過於教條化
WebWork:
優點:比Struts便於使用
缺點:複雜的UI難於維護,UI代碼過於複雜(JSF作者對action
Framework都攻擊這一點)
Tapestry:
優點:概念新穎;可以應付複雜的UI
缺點:對於一個組件化(JSF主要競爭者),它依然依附於page/action的概念

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
他認為JSF這個標準下這些應該有第三方提供。JSF(2.0)會提供"Partial Faces Request",它是Ajax實現。JSF也會增強annotation組建編程。

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?很多JSF書都拿Struts作為對比。他認為這不能體現JSF的特點。他認為Struts和WebWork能做到的JSF也能做到。

6、你對Ruby on Rails的看法如何?
它與WebWork一樣好用,它的CoC(Convention over Configration)和腳手架非常好用。他認為CoC可以被應用在任何framework,他認為這是RoR最大的優點。他還認為RoR會走上其它framework的路(複雜性),因為人們需要自己的擴充。

RIFE(Geert Bevin)

1、你認為你的framework的"甜點"在哪裡?他最適合哪種類型的項目?
你可以付出10%的工作量,得到其它framework的90%的......,它是一個full-stack framework(如RoR)。它吸收了成熟的分層架構的架構,並將共同的優點彙集在一起。提供了web continuation,POJO驅動的CRUD產生,可擴充的基於組建的架構,無session的狀態控制,關注REST作為API,雙向無邏輯模版引擎,整合了內容控制架構(CMS?)。每個層次的組建提供了可複用性(AOP,site,sub-site,page,widget,portlet等)。適合於團隊快速開發公用Web項目,適合喜歡開發可複用組件的人。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
團隊中的每個人都有其它framework的知識,難於培訓他們。開發狀態相關的伺服器端Web組件,而不是用RIA或Ajax去實現。第三方支援很重要的情況下(可憐RIFE使用者群還不大)。他推薦這種情況下使用JSF。或者在XML為主要發布形式的情況下,推薦Cocoon。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
他實驗過WebWork,JSF,Wicket。他喜歡WebWork的簡單,但是不喜歡它的模版方式(tag的template,應該),它也不提供組件封裝。他認為JSF的工具支援非常吸引人。Wicket的純Java實現很不錯,可惜XML配置很不爽。

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
關於Ajax,RIFE剛剛整合了DWR,而且選定以後也使用這個。整合Dojo,Scriptaculous,Prototype都很容易整合進來。

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?這些錯誤理念:
  1)、RIFE的XML配置繁瑣
  2)、RIFE是continuations server
  3)、RIFE重新造輪子沒有提供新鮮東西
  4)、RIFE的模版文法很蹩腳過於簡單和業餘
  5)、RIFE是基於request的framework
  6)、RIFE的功能太多,學習曲線陡峭

6、你對Ruby on Rails的看法如何?
RoR對Java社區的衝擊非常棒,元編成也得到了信任。RoR沒什麼特殊之處,也沒有從Ruby語言獲益很多。
我討厭:它的模版。Partials(RoR中的組件)。URL的分散處理。Active Record提供了從資料庫schema而來的DSL,但是卻不是從domain model而來。沒有l10n和i18n支援。手動狀態轉換。不能在JVM運行(......)。實際上腳手架產生了實際代碼。Ruby缺少工具和IDE。

Seam(Gavin King)

1、你認為你的framework的"甜點"在哪裡?他最適合哪種類型的項目?
擁有豐富使用者互動體驗的應用。方便實現多視窗的操作,回退的支援,單視窗多工作區,無狀態瀏覽。對商務流程(BPM)的整合是獨一無二的。Seam方便使用資料驅動的ORM。遵循JSF和EJB3,多任務支援(多視窗/多工作區),BPM的領先解決方案。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
不適合只是將資料從資料庫顯示到網頁的應用,這時應該使用PHP或RoR。不適合需要設計特別的HTML組件的情況,此時應該選用Tapestry或Wicket。還在使用JDK1.4的人們。還有那些喜歡Struts的人(嘿嘿,夠狠)。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
JSF:喜歡他的事件/互動模型。喜歡他的EL和模型繫結。不喜歡那麼多XML(為什麼沒有annotation)。建立自己的controls太難了。
Tapestry:非常好。form驗證是它的殺手鐧!模版方式很有創意。不過非基於POJO的組件模型則讓我對它失去興趣。
RIFE:這個東西很怪,但是有創業也有趣。我想進一步學習。如果學習先要自費武功:D
Struts:這個東西的模型view綁定太複雜了。東西已經過時了。
WebWork:比Struts好一點,不過也過時了。XWork曾經是個很好的實現,不過現在也過時了。

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
Portal支援。遠程架構Seam Remoting Framework(Ajax)。模版訊息的工具支援。以後還要整合ESB,計劃引擎和非同步支援。

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?
這些都不是真的:JSF不能處理GET requests。JSF post後無法redirect。JSF不能與REST共存。

6、你對Ruby on Rails的看法如何?
它是PHP的很好替代品。如果它有一個正經一點的持久化層它就可以和Java競爭了。

Spring MVC(Rob Harrop)和Spring Web Flow(Rob Harrop and Keith Donald)

1、你認為你的framework的"甜點"在哪裡?他最適合哪種類型的項目?
Spring MVC:
穩定可擴充,支援了i18n、檔案上傳、異常處理,這些穩定的支援給開發人員堅實的工作基礎。是最佳實務,告訴你怎麼做是最好的。與Spring整合,領先的IoC遠生支援。支援,Spring社區活躍和龐大。Struts開發人員可以平滑過渡。適合多種項目,可選的多種result類型。
Spring Web Flow:內建任務處理引擎,支援線性處理過程中的持續狀態。抽象,減少開發的關注點。適合多種項目類型,外掛程式支援Spring MVC、Struts、JSF等。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
Spring MVC:不適合需要組件化開發的情境。它是一個request驅動的MVC。那些情境推薦JSF或Tapestry。
Spring Web Flow:處理線性頁面流,不適合一般的"自由瀏覽"。當然Spring Web Flow可以與request驅動或者組件驅動共存。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
Spring架構支援Struts和JSF整合。

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
Spring MVC:簡化JSP標籤。更多的MVC配置schema。CoC風格的預設控制器、URL影射、view,學習Rails和Stripes的優點。增強資料繫結和驗證(支援範型綁定)。Portlet支援。Spring也要接受Ajax,使用DWR庫。
Spring Web Flow:一大堆,關心的可以自己看......

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?
Spring MVC難於配置。在Spring 2.0,將會改善,可以使用自己定義的基於schema的配置。

6、你對Ruby on Rails的看法如何?
Spring MVC:RoR非常有趣。不過現在就拿出來用還有點幼稚。這裡舉了個例子,關於變數的複數形式的處理,RoR會使用這樣的CoC風格來處理變數list,而Spring MVC也實驗了種種風格,但是受到的結果卻很差。人們認為英語的複數很古怪,沒有一定的規則,所以會帶來混亂,如(person -> people)。所以Spring ...

Stripes(Tim Fennell)

1、你認為你的framework的“甜點”在哪裡?他最適合哪種類型的項目?
與Spring MVC、WebWork等相同。它提供高品質action驅動的架構的同時,盡量簡化配置,增進開發效率。Stripes適合複雜的資料互動的場合。這種情況下綁定驗證的強項就完全體現出來了,能夠很好的處理form和map轉換等。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
所有的action驅動的framework都適合使用者在非Ajax驅動的情況下在一個頁面進行松關聯(loosely
related)和無狀態互動的情況。適合每次都重新整理的頁面。管理多視窗間持續狀態的應用會比較麻煩,此時應該選擇JSF。不過我認為90%以上的Web程式都是前者,JSF只適合剩下的那9%,AJAX對於管理無狀態UI更加適合。用戶端不需要AJAX,則可以看看Wicket,它更加簡單。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
用過Struts、WebWork、Spring MVC。其中Struts做過商業項目,不過這個東西帶來的麻煩遠比帶來的效率提升要多。它認為這些MVC都有三個缺點:暴露了過多的複雜性給可發者。沒有提供足夠的開發便利性,沒有提供足夠多的錯誤和提示資訊,也沒有date格式化等小的便利(其實有)。穩當太差。

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
1.3要加入Inteceptor,實現AOP功能。驗證系統要加強。支援Ajax。我還在尋找一個好的Ajax/javascript庫。

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?
這些觀點:1、Stripes使用了annotation代替XML,只是換湯不換藥:由於中繼資料更接近代碼,所以修改預設的配置非常方便,不像XML那樣複雜,這是實質的變化。2、Annotation意味著你只能有一套配置:我認為90%的action都有自己的一套配置!Stripes會根據繼承關係尋找Annotations,子類的annotation會覆蓋父類的,因為像validation都是可以繼承的,如果特別需要還可以覆蓋。這樣很合理。在1.3中允許validations基於UI事件進行。它向後相容,不需要可以不用。

6、你對Ruby on Rails的看法如何?
我認為Java社區有很多可以從RoR學習的地方。Stripes學習了RoR的前端部分,開發人員可以減少配置量。但是RoR的RHTML讓我想到了以前的JSP中混亂的scriptlet。而後面的ActiveRecord是一個很好的理念,實現的也很好。ActiveRecord比Hibernate等複雜的ORM工具要容易理解,因為這樣的特點RoR才引起了這麼大的波瀾。

Struts Action 1(Don Brown)

1、你認為你的framework的“甜點”在哪裡?他最適合哪種類型的項目?
文檔和使用者基礎,書籍和背後的支援。容易僱到人(也容易找工作)。雖然其他項目的理念比這個要先進,但是這些不算什麼。實際上,Web層是很容易也很直接的。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
如果你需要portlets或者複雜的頁面(顯示很多東西),那麼Struts要麼無法工作要麼太枯燥。這種情況你需要一個基於組件的framework,如JSF、Tapestry/Wicket。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
這些我基本都實驗過,他們每個都工作的很不錯。

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
Struts Action2基於WebWork2,很快會開始。現在已經支援Ajax了,我們在尋找更加容易的開發方式,JSF支援(Struts Shale),continuation支援,還有支援更多的指令碼語言(BSF擴充指令碼撰寫Action)。

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?
Struts太過時了,而且也不酷,難於使用。但是你可以自己修改或者擴充它。我認為團隊對於你的限制遠大於framework對你的限制。

6、你對Ruby on Rails的看法如何?
不需要D&D工具,旨在協助開發人員提高開發效率的好例子。我們在Action2中將學習它的先進理念。

Tapestry(Howard Lewis Ship)

1、你認為你的framework的“甜點”在哪裡?他最適合哪種類型的項目?
我想Tapestry對於中等規模或者大規模的應用會帶來很多好處(甚至你可以在單頁面的應用程式中獲得好處)。這裡有允許你建立新的組件的良好工具。Tapestry不關心資料從哪裡來,很多“項目類型”都基於切面(aspect)(如CRUD vs. RSS feed vs. etc.)。我認為Tapestry非常容易與IoC整合(HiveMind或與Spring),方便進行測試。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
我在其它Java framework中沒有找到到強於Tapestry的優點。但是對於RoR,我自己沒有使用過使用,很難說RoR中的項目應該是什麼樣子。我沒有仔細對比過RIFE,它看起來受了RoR影響,尤其是類似ActiveRecord的資料訪問層。但是如果你的應用需要特定的URL格式,那麼在Tapestry中奮戰勝算不大。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
在這兩年來我沒怎麼嘗試過Tapestry以外的東西。我沒怎麼學習RoR,因為時間太有限了。

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
Tapestry 4.0有很好的Ajax支援,通過Tacos庫。而Tapestry4.1還要進一步強化這方面的支援。
Tapestry 5.0提供了明顯的改進:沒有abstract類(Tapestry的怪癖:)。沒有強迫的繼承關係。對屬性進行annotation而不是方法。沒有XML,只有模版和annotaions。只能類裝載,自動尋找類的變化。最小化API,超越annotaion。面向方面(Aspect-oriented)模組構造,使用mix-ins。

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?
Tapestry3.0還不容易測試,4.0改善了一些。Tapestry只是個人秀;實際上我們有很多活躍的貢獻者。Tapestry的學習曲線非場陡峭。它只有漂亮的模版實現;實際上Tapestry的特點在於狀態管理(允許Object Storage Service狀態,而不是多線程的單例來管理requests之間的游離和持久狀態)

6、你對Ruby on Rails的看法如何?
很有影響力。但是模版的實現非常醜陋。我聽到了很多意見,關於RoR的優缺點。基於我的基本理解,這些觀念對Tapestry4產生了影響(它對Tapestry 5影響更深)。
RoR意味著限制了你的選擇:如果你選擇RoR那麼就要尊旬它的實踐(CoC..),看起來你的錢會花的恨值。這些類似Microsoft的哲學。而Java更崇尚給你更寬鬆的選擇,不限定你使用的工具,但是曖昧的說這需要你對你的工具理解更深。不僅對Tapestry,還對於JEE、Spring這寫entire stack的架構,需要從RoR學習,不僅提供工具,還需要提供整套的解決方案。

Trails(Chris Nelson)

1、你認為你的framework的“甜點”在哪裡?他最適合哪種類型的項目?
Trails的應用程式只需要Web介面和持久化的domain model就可以了。Trails給你的domain
model快速的提供一個介面,除了POJO自己不需要附加的代碼。Trails允許你修改介面的外觀和行為,包括驗證、i18n、安全。這些都不需要java代碼產生,不喜歡代碼產生的人應該感覺很舒適。

2、它不適合於什麼樣的情境?在這些情境你推薦什麼fremework?它是哪個?
Trails講究夠用就好。它允許你快速交付,問問你的客戶:“這樣夠好嗎?”。這會改變你的工作流程,當然這不是可以覆蓋所有需求的解決方案。當UI需求很高,Trails沒有優勢。我認為Trails適合於混合的應用,對於管理員他們只需要夠用就好,那麼就可以使用Trails。其它的部分我們可以訂製開發,我們在使用Tapestry、Hibernate、Spring來實現這些部分,Trails正是基於它們。對於非互動的應用,Trails也不適合,如報表應用,可以考慮Eclipse BIRT。

3、在下面提到的framework中,你實驗過他們嗎?如果實驗過,你比較喜歡哪個?你不喜歡哪個?
我用Struts很多。它曾經是偉大的framework。主要的缺陷是它不能自動幫定資料到domain model。我也研究過JSF,它比Struts強,但是自訂群組建非常難。Tapestry非常便於自訂群組建,尤其對於建立高階組件(有其它組件組成的)非常方便,Trails正在使用它。

4、你的framework的未來會怎樣?對於使用者開發會有什麼方便使用的變化?你會原生支援Ajax嗎?你們計劃支援它了嗎?
對於Trails來說我們站在巨人的肩膀上。Tapestry在ajax功能作了很多努力,所以Trails也不難與其共舞。但是我們需要建立更多的例子來示範這些。我們也致力於讓Trails容易介入到已經進行的項目中。以後Trails還要加入基於執行個體的安全(instance-based security)(目前正在使用基於角色的role-based),還有method invocation。

5、有對你們的framework的傳言需要澄清嗎?如果有,是哪個?
Trails是對RoR的移植。Trails的名字來自Rails。它是基於Rails的理念,但不是對它的移植。

6、你對Ruby on Rails的看法如何?
我認為我們有很多需要從RoR學習的地方,那將協助我們享受開發Web程式的愜意。

相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。