Java Web 框架的"甜點(diǎn)"

2019-11-18 12:51:36

字體：大中小

供稿：網(wǎng)友

這是一篇很有趣的文檔，所以摘要一下，其實(shí)類似閱讀筆記，似乎是3/25發(fā)布的：
不知怎么翻譯Sweet Spots，難道翻譯為甜處、甜頭、蜜點(diǎn)、蜜穴？

本文基于對以下人的采訪（最后兩位的看法獨(dú)到還是自己看吧！）：
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、你認(rèn)為你的framework的"甜點(diǎn)"在哪里？他最適合哪種類型的項(xiàng)目？
當(dāng)你希望瀏覽器程序像桌面程序一樣工作的時候，你可以遵循標(biāo)準(zhǔn)并獲得大量第三方支持。它致力于降低復(fù)雜度。它答應(yīng)你不與view和特定的action、參數(shù)傳遞、狀態(tài)傳遞、渲染打交道就可以進(jìn)行高質(zhì)量的開發(fā)，不管是否使用工具。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
它不適合大規(guī)模的、只讀（其實(shí)指讀為主）的網(wǎng)站。在這種情況推薦Struts，因?yàn)橹R庫豐富（應(yīng)該指文檔和用戶群）。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
Seam：
優(yōu)點(diǎn)：非常簡單直接
缺點(diǎn)：對于大項(xiàng)目過于簡單；沒有模塊化開發(fā)的好例子
Struts：
優(yōu)點(diǎn)：巨大的文檔和用戶群；跟著它沒錯
缺點(diǎn)：狀態(tài)/行為的分離過于教條化
WebWork：
優(yōu)點(diǎn)：比Struts易于使用
缺點(diǎn)：復(fù)雜的UI難于維護(hù)，UI代碼過于復(fù)雜（JSF作者對action
Framework都攻擊這一點(diǎn)）
Tapestry：
優(yōu)點(diǎn)：概念新奇；可以應(yīng)付復(fù)雜的UI
缺點(diǎn)：對于一個組件化（JSF主要競爭對手），它依然依附于page/action的概念

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
他認(rèn)為JSF這個標(biāo)準(zhǔn)下這些應(yīng)該有第三方提供。JSF(2.0)會提供"Partial Faces Request"，它是Ajax實(shí)現(xiàn)。JSF也會增強(qiáng)annotation組建編程。

5、有對你們的framework的傳言需要澄清么？假如有，是哪個？很多JSF書都拿Struts作為對比。他認(rèn)為這不能體現(xiàn)JSF的特點(diǎn)。他認(rèn)為Struts和WebWork能做到的JSF也能做到。

6、你對Ruby on Rails的看法如何？
它與WebWork一樣好用，它的CoC（Convention over Configration）和腳手架非常好用。他認(rèn)為CoC可以被應(yīng)用在任何framework，他認(rèn)為這是RoR最大的優(yōu)點(diǎn)。他還認(rèn)為RoR會走上其它framework的路（復(fù)雜性），因?yàn)槿藗冃枰约旱臄U(kuò)展。

RIFE(Geert Bevin)

1、你認(rèn)為你的framework的"甜點(diǎn)"在哪里？他最適合哪種類型的項(xiàng)目？
你可以付出10%的工作量，得到其它framework的90%的......，它是一個full-stack framework（如RoR）。它吸收了成熟的分層框架的架構(gòu)，并將共同的優(yōu)點(diǎn)匯集在一起。提供了web continuation，POJO驅(qū)動的CRUD生成，可擴(kuò)展的基于組建的架構(gòu)，無session的狀態(tài)控制，關(guān)注REST作為API，雙向無邏輯模版引擎，集成了內(nèi)容控制框架（CMS？）。每個層次的組建提供了可復(fù)用性（AOP，site，sub-site，page，widget，portlet等）。適合于團(tuán)隊(duì)快速開發(fā)公共Web項(xiàng)目，適合喜歡開發(fā)可復(fù)用組件的人。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
團(tuán)隊(duì)中的每個人都有其它framework的知識，難于培訓(xùn)他們。開發(fā)狀態(tài)相關(guān)的服務(wù)器端Web組件，而不是用RIA或Ajax去實(shí)現(xiàn)。第三方支持很重要的情況下（可憐RIFE用戶群還不大）。他推薦這種情況下使用JSF。或者在xml為主要發(fā)布形式的情況下，推薦Cocoon。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
他試驗(yàn)過WebWork，JSF，Wicket。他喜歡WebWork的簡單，但是不喜歡它的模版方式（tag的template，應(yīng)該），它也不提供組件封裝。他認(rèn)為JSF的工具支持非常吸引人。Wicket的純java實(shí)現(xiàn)很不錯，可惜XML配置很不爽。

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
關(guān)于Ajax，RIFE剛剛集成了DWR，而且選定以后也使用這個。集成Dojo，Scriptaculous，Prototype都很輕易集成進(jìn)來。

5、有對你們的framework的傳言需要澄清么？假如有，是哪個？這些錯誤理念：
  1)、RIFE的XML配置繁瑣
  2)、RIFE是continuations server
  3)、RIFE重新造輪子沒有提供新鮮東西
  4)、RIFE的模版語法很蹩腳過于簡單和業(yè)余
  5)、RIFE是基于request的framework
  6)、RIFE的功能太多，學(xué)習(xí)曲線陡峭

6、你對Ruby on Rails的看法如何？
RoR對Java社區(qū)的沖擊非常棒，元編成也得到了信任。RoR沒什么非凡之處，也沒有從Ruby語言獲益很多。
我討厭：它的模版。Partials（RoR中的組件）。URL的分散處理。Active Record提供了從數(shù)據(jù)庫schema而來的DSL，但是卻不是從domain model而來。沒有l(wèi)10n和i18n支持。手動狀態(tài)轉(zhuǎn)換。不能在JVM運(yùn)行（......）。實(shí)際上腳手架生成了實(shí)際代碼。Ruby缺少工具和IDE。

Seam(Gavin King)

1、你認(rèn)為你的framework的"甜點(diǎn)"在哪里？他最適合哪種類型的項(xiàng)目？
擁有豐富用戶交互體驗(yàn)的應(yīng)用。方便實(shí)現(xiàn)多窗口的操作，回退的支持，單窗口多工作區(qū)，無狀態(tài)瀏覽。對商務(wù)流程（BPM）的集成是獨(dú)一無二的。Seam方便使用數(shù)據(jù)驅(qū)動的ORM。遵循JSF和EJB3，多任務(wù)支持（多窗口/多工作區(qū)），BPM的領(lǐng)先解決方案。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
不適合只是將數(shù)據(jù)從數(shù)據(jù)庫顯示到網(wǎng)頁的應(yīng)用，這時應(yīng)該使用php或RoR。不適合需要設(shè)計(jì)非凡的Html組件的情況，此時應(yīng)該選用Tapestry或Wicket。還在使用JDK1.4的人們。還有那些喜歡Struts的人（嘿嘿，夠狠）。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
JSF：喜歡他的事件/交互模型。喜歡他的EL和模型綁定。不喜歡那么多XML（為什么沒有annotation）。創(chuàng)建自己的controls太難了。
Tapestry：非常好。form驗(yàn)證是它的殺手锏！模版方式很有創(chuàng)意。不過非基于POJO的組件模型則讓我對它失去愛好。
RIFE：這個東西很怪，但是有創(chuàng)業(yè)也有趣。我想進(jìn)一步學(xué)習(xí)。假如學(xué)習(xí)先要自費(fèi)武功:D
Struts：這個東西的模型view綁定太復(fù)雜了。東西已經(jīng)過時了。
WebWork：比Struts好一點(diǎn)，不過也過時了。XWork曾經(jīng)是個很好的實(shí)現(xiàn)，不過現(xiàn)在也過時了。

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
Portal支持。遠(yuǎn)程框架Seam Remoting Framework（Ajax）。模版消息的工具支持。以后還要集成ESB，計(jì)劃引擎和異步支持。

5、有對你們的framework的傳言需要澄清么？假如有，是哪個？
這些都不是真的：JSF不能處理GET requests。JSF post后無法redirect。JSF不能與REST共存。

6、你對Ruby on Rails的看法如何？
它是PHP的很好替代品。假如它有一個正經(jīng)一點(diǎn)的持久化層它就可以和Java競爭了。

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

1、你認(rèn)為你的framework的"甜點(diǎn)"在哪里？他最適合哪種類型的項(xiàng)目？
Spring MVC：
穩(wěn)定可擴(kuò)展，支持了i18n、文件上傳、異常處理，這些穩(wěn)定的支持給開發(fā)者堅(jiān)實(shí)的工作基礎(chǔ)。是最佳實(shí)踐，告訴你怎么做是最好的。與Spring集成，領(lǐng)先的IoC遠(yuǎn)生支持。支持，Spring社區(qū)活躍和龐大。Struts開發(fā)者可以平滑過渡。適合多種項(xiàng)目，可選的多種result類型。
Spring Web Flow：內(nèi)置任務(wù)處理引擎，支持線性處理過程中的持續(xù)狀態(tài)。抽象，減少開發(fā)的關(guān)注點(diǎn)。適合多種項(xiàng)目類型，插件支持Spring MVC、Struts、JSF等。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
Spring MVC：不適合需要組件化開發(fā)的場景。它是一個request驅(qū)動的MVC。那些場景推薦JSF或Tapestry。
Spring Web Flow：處理線性頁面流，不適合一般的"自由瀏覽"。當(dāng)然Spring Web Flow可以與request驅(qū)動或者組件驅(qū)動共存。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
Spring框架支持Struts和JSF集成。

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
Spring MVC：簡化jsp標(biāo)簽。更多的MVC配置schema。CoC風(fēng)格的默認(rèn)控制器、URL影射、view，學(xué)習(xí)Rails和Stripes的優(yōu)點(diǎn)。增強(qiáng)數(shù)據(jù)綁定和驗(yàn)證（支持范型綁定）。Portlet支持。Spring也要接受Ajax，使用DWR庫。
Spring Web Flow：一大堆，關(guān)心的可以自己看......

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

6、你對Ruby on Rails的看法如何？
Spring MVC：RoR非常有趣。不過現(xiàn)在就拿出來用還有點(diǎn)幼稚。這里舉了個例子，關(guān)于變量的復(fù)數(shù)形式的處理，RoR會使用這樣的CoC風(fēng)格來處理變量list，而Spring MVC也實(shí)驗(yàn)了種種風(fēng)格，但是受到的結(jié)果卻很差。人們認(rèn)為英語的復(fù)數(shù)很古怪，沒有一定的規(guī)則，所以會帶來混亂，如（person -> people）。所以Spring ...

Stripes(Tim Fennell)

1、你認(rèn)為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類型的項(xiàng)目？
與Spring MVC、WebWork等相同。它提供高質(zhì)量action驅(qū)動的框架的同時，盡量簡化配置，增進(jìn)開發(fā)效率。Stripes適合復(fù)雜的數(shù)據(jù)交互的場合。這種情況下綁定驗(yàn)證的強(qiáng)項(xiàng)就完全體現(xiàn)出來了，能夠很好的處理form和map轉(zhuǎn)換等。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
所有的action驅(qū)動的framework都適合用戶在非Ajax驅(qū)動的情況下在一個頁面進(jìn)行松關(guān)聯(lián)（loosely
related）和無狀態(tài)交互的情況。適合每次都刷新的頁面。治理多窗口間持續(xù)狀態(tài)的應(yīng)用會比較麻煩，此時應(yīng)該選擇JSF。不過我認(rèn)為90%以上的Web程序都是前者，JSF只適合剩下的那9%，AJAX對于治理無狀態(tài)UI更加適合。客戶端不需要AJAX，則可以看看Wicket，它更加簡單。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
用過Struts、WebWork、Spring MVC。其中Struts做過商業(yè)項(xiàng)目，不過這個東西帶來的麻煩遠(yuǎn)比帶來的效率提升要多。它認(rèn)為這些MVC都有三個缺點(diǎn)：暴露了過多的復(fù)雜性給可發(fā)者。沒有提供足夠的開發(fā)便利性，沒有提供足夠多的錯誤和提示信息，也沒有date格式化等小的便利（其實(shí)有）。穩(wěn)當(dāng)太差。

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
1.3要加入Inteceptor，實(shí)現(xiàn)AOP功能。驗(yàn)證系統(tǒng)要加強(qiáng)。支持Ajax。我還在尋找一個好的Ajax/Javascript庫。

5、有對你們的framework的傳言需要澄清么？假如有，是哪個？
這些觀點(diǎn)：1、Stripes使用了annotation代替XML，只是換湯不換藥：由于元數(shù)據(jù)更接近代碼，所以修改默認(rèn)的配置非常方便，不像XML那樣復(fù)雜，這是實(shí)質(zhì)的變化。2、Annotation意味著你只能有一套配置：我認(rèn)為90%的action都有自己的一套配置！Stripes會根據(jù)繼續(xù)關(guān)系尋找Annotations，子類的annotation會覆蓋父類的，因?yàn)橄駐alidation都是可以繼續(xù)的，假如非凡需要還可以覆蓋。這樣很合理。在1.3中答應(yīng)validations基于UI事件進(jìn)行。它向后兼容，不需要可以不用。

6、你對Ruby on Rails的看法如何？
我認(rèn)為Java社區(qū)有很多可以從RoR學(xué)習(xí)的地方。Stripes學(xué)習(xí)了RoR的前端部分，開發(fā)者可以減少配置量。但是RoR的RHTML讓我想到了以前的JSP中混亂的scriptlet。而后面的ActiveRecord是一個很好的理念，實(shí)現(xiàn)的也很好。ActiveRecord比Hibernate等復(fù)雜的ORM工具要輕易理解，因?yàn)檫@樣的特點(diǎn)RoR才引起了這么大的波瀾。

Struts Action 1(Don Brown)

1、你認(rèn)為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類型的項(xiàng)目？
文檔和用戶基礎(chǔ)，書籍和背后的支持。輕易雇到人（也輕易找工作）。雖然其他項(xiàng)目的理念比這個要先進(jìn)，但是這些不算什么。實(shí)際上，Web層是很輕易也很直接的。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
假如你需要portlets或者復(fù)雜的頁面（顯示很多東西），那么Struts要么無法工作要么太枯燥。這種情況你需要一個基于組件的framework，如JSF、Tapestry/Wicket。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
這些我基本都試驗(yàn)過，他們每個都工作的很不錯。

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
Struts Action2基于WebWork2，很快會開始。現(xiàn)在已經(jīng)支持Ajax了，我們在尋找更加輕易的開發(fā)方式，JSF支持（Struts Shale），continuation支持，還有支持更多的腳本語言（BSF擴(kuò)展腳本撰寫Action）。

5、有對你們的framework的傳言需要澄清么？假如有，是哪個？
Struts太過時了，而且也不酷，難于使用。但是你可以自己修改或者擴(kuò)展它。我認(rèn)為團(tuán)隊(duì)對于你的限制遠(yuǎn)大于framework對你的限制。

6、你對Ruby on Rails的看法如何？
不需要D&D工具，旨在幫助開發(fā)人員提高開發(fā)效率的好例子。我們在Action2中將學(xué)習(xí)它的先進(jìn)理念。

Tapestry(Howard Lewis Ship)

1、你認(rèn)為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類型的項(xiàng)目？
我想Tapestry對于中等規(guī)模或者大規(guī)模的應(yīng)用會帶來很多好處（甚至你可以在單頁面的應(yīng)用程序中獲得好處）。這里有答應(yīng)你創(chuàng)建新的組件的良好工具。Tapestry不關(guān)心數(shù)據(jù)從哪里來，很多“項(xiàng)目類型”都基于切面（aspect）（如CRUD vs. rss feed vs. etc.）。我認(rèn)為Tapestry非常輕易與IoC集成（HiveMind或與Spring），方便進(jìn)行測試。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
我在其它Java framework中沒有找到到強(qiáng)于Tapestry的優(yōu)點(diǎn)。但是對于RoR，我自己沒有使用過使用，很難說RoR中的項(xiàng)目應(yīng)該是什么樣子。我沒有仔細(xì)對比過RIFE，它看起來受了RoR影響，尤其是類似ActiveRecord的數(shù)據(jù)訪問層。但是假如你的應(yīng)用需要特定的URL格式，那么在Tapestry中奮戰(zhàn)勝算不大。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
在這兩年來我沒怎么嘗試過Tapestry以外的東西。我沒怎么學(xué)習(xí)RoR，因?yàn)闀r間太有限了。

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
Tapestry 4.0有很好的Ajax支持，通過Tacos庫。而Tapestry4.1還要進(jìn)一步強(qiáng)化這方面的支持。
Tapestry 5.0提供了明顯的改進(jìn)：沒有abstract類（Tapestry的怪癖:）。沒有強(qiáng)迫的繼續(xù)關(guān)系。對屬性進(jìn)行annotation而不是方法。沒有XML，只有模版和annotaions。只能類裝載，自動尋找類的變化。最小化API，超越annotaion。面向方面（Aspect-oriented）模塊構(gòu)造，使用mix-ins。

5、有對你們的framework的傳言需要澄清么？假如有，是哪個？
Tapestry3.0還不輕易測試，4.0改善了一些。Tapestry只是個人秀；實(shí)際上我們有很多活躍的貢獻(xiàn)者。Tapestry的學(xué)習(xí)曲線非場陡峭。它只有漂亮的模版實(shí)現(xiàn)；實(shí)際上Tapestry的特點(diǎn)在于狀態(tài)治理（答應(yīng)對象存儲狀態(tài)，而不是多線程的單例來治理requests之間的游離和持久狀態(tài)）

6、你對Ruby on Rails的看法如何？
很有影響力。但是模版的實(shí)現(xiàn)非常丑陋。我聽到了很多意見，關(guān)于RoR的優(yōu)缺點(diǎn)。基于我的基本理解，這些觀念對Tapestry4產(chǎn)生了影響（它對Tapestry 5影響更深）。
RoR意味著限制了你的選擇：假如你選擇RoR那么就要尊旬它的實(shí)踐（CoC..），看起來你的錢會花的恨值。這些類似Microsoft的哲學(xué)。而Java更崇尚給你更寬松的選擇，不限定你使用的工具，但是曖昧的說這需要你對你的工具理解更深。不僅對Tapestry，還對于JEE、Spring這寫entire stack的框架，需要從RoR學(xué)習(xí)，不僅提供工具，還需要提供整套的解決方案。

Trails(Chris Nelson)

1、你認(rèn)為你的framework的“甜點(diǎn)”在哪里？他最適合哪種類型的項(xiàng)目？
Trails的應(yīng)用程序只需要Web界面和持久化的domain model就可以了。Trails給你的domain
model快速的提供一個界面，除了POJO自己不需要附加的代碼。Trails答應(yīng)你修改界面的外觀和行為，包括驗(yàn)證、i18n、安全。這些都不需要java代碼生成，不喜歡代碼生成的人應(yīng)該感覺很舒適。

2、它不適合于什么樣的場景？在這些場景你推薦什么fremework？它是哪個？
Trails講究夠用就好。它答應(yīng)你快速交付，問問你的客戶：“這樣夠好么？”。這會改變你的工作流程，當(dāng)然這不是可以覆蓋所有需求的解決方案。當(dāng)UI需求很高，Trails沒有優(yōu)勢。我認(rèn)為Trails適合于混合的應(yīng)用，對于治理員他們只需要夠用就好，那么就可以使用Trails。其它的部分我們可以訂制開發(fā)，我們在使用Tapestry、Hibernate、Spring來實(shí)現(xiàn)這些部分，Trails正是基于它們。對于非交互的應(yīng)用，Trails也不適合，如報(bào)表應(yīng)用，可以考慮Eclipse BIRT。

3、在下面提到的framework中，你試驗(yàn)過他們么？假如試驗(yàn)過，你比較喜歡哪個？你不喜歡哪個？
我用Struts很多。它曾經(jīng)是偉大的framework。主要的缺陷是它不能自動幫定數(shù)據(jù)到domain model。我也研究過JSF，它比Struts強(qiáng)，但是自定義組建非常難。Tapestry非常便于自定義組建，尤其對于建立高階組件（有其它組件組成的）非常方便，Trails正在使用它。

4、你的framework的未來會怎樣？對于用戶開發(fā)會有什么方便使用的變化？你會原生支持Ajax么？你們計(jì)劃支持它了么？
對于Trails來說我們站在巨人的肩膀上。Tapestry在ajax功能作了很多努力，所以Trails也不難與其共舞。但是我們需要創(chuàng)建更多的例子來演示這些。我們也致力于讓Trails輕易介入到已經(jīng)進(jìn)行的項(xiàng)目中。以后Trails還要加入基于實(shí)例的安全（instance-based security）（目前正在使用基于角色的role-based），還有method invocation。

5、有對你們的framework的傳言需要澄清么？假如有，是哪個？
Trails是對RoR的移植。Trails的名字來自Rails。它是基于Rails的理念，但不是對它的移植。

6、你對Ruby on Rails的看法如何？
我認(rèn)為我們有很多需要從RoR學(xué)習(xí)的地方，那將幫助我們享受開發(fā)Web程序的舒服。

上一篇：WLP8.1 CMS 使用經(jīng)驗(yàn)

下一篇：使用WEBLOGIC PORTAL規(guī)則引擎中實(shí)現(xiàn)動態(tài)業(yè)務(wù)邏輯