Web架構比較

Blog好久沒有更新了, 最近一直忙於一個新項目,在這個項目中嘗試很多新的做法,準備收集一下放上blog來,這裡先放一篇關於Web架構的,基本是老調重談了. 該文寫於4月,主要是為了和朋友討論問題,有些地方可能不正確

	Struts	JSF	Tapestry	ASP.NET
Architecture	跳轉模型 MVC	跳轉模型 Front Controller+組件化編程	頁面模型 Page Controller+組件化編程	頁面模型 Page Controller+組件化編程
Programming Model	商務邏輯： Struts1中需要繼承基類；Struts2是POJO的模型； 頁面邏輯： 有很不同實現，可以是JSP，也可以是通過模版引擎渲染。	商務邏輯： POJO的編程風格； 頁面邏輯： 主要是JSP，也可以用HTML風格。	商務邏輯： Taperstry4需要繼承基類；但Taperstry5就是POJO風格； 頁面邏輯： 普通的HTML。	商務邏輯： 需要繼承基類； 頁面邏輯： 類似JSP，但不同的是，該頁面實際是商務邏輯類的子類。
Request Process		由官方定義的六個步驟組成；	取決於Engine Service。	由官方定義的15個步驟組成。
Navigation	Path和Action綁定，需要設定檔解析。	通過faces-config.xml設定檔完成。	URL是全域的，沒有額外的設定檔； 除非顯式跳轉，所以行為都在本Page上。 而跳轉分兩種： 1. DirectLink寫在頁面上 2. 在代碼邏輯中定義頁面跳轉邏輯。	同Tapestry類似。
Event handling	無	頁面定義事件發起；兩種方式參數傳遞方式：一種分離傳遞；另一種通過FacesContext。	頁面定義事件發起；直接賦予參數，沒有參數個數限制；除此外還有內建的生命週期相關的event	類似Swing的事件控制方式。
Component State	無	沒有狀態維護機制，每次request都從建組件。	提供組件狀態的維護機制。	提供組件狀態的維護機制。
Component Dev	無	基於JSP Tag的開發方式。	開發方式類似Page, 邏輯代碼和頁面分離，頁面輸出使用HTML。	開發方式類似Page；邏輯代碼和頁面分離；頁面輸出可以複用已有的組件
View	有很不同實現，可以是JSP，也可以是通過模版引擎渲染。	主要是JSP，也可以用HTML風格。	HTML	類似JSP頁面。
Validation and Conversion		提供了多種方式支援，但用戶端驗證支援不好，同時在form一級的支援不好，通常需要項目自己定製。	同樣提供多種方式支援；此外提供用戶端的Validation；天然地支援form一級支援。	類似Tapestry。
I18N	較好的支援。	較好的支援。	很好的支援，額外提供預覽功能。
Testability	Struts1的測試不容易，Strut2測試容易簡單。	測試支援簡單容易。	Tapestry4的測試不容易，不過Tapestry5的測試可以很簡單。	不容易測試。
Extensibility		良好	良好	良好
Industry Momentum	廣泛使用，目前各種資源都不錯。	JSF業界標準，業內廠商支援會比較多，不過未必不會出現EJB2的結局。	應用範圍小於Struts，之前的版本學習曲線太高。	微軟地主老財，有大把的錢；此外，大量的第三方公司提供支援。
Migrate		從Struts遷移不難；	從Struts或者JSP遷移難度較大些。

因為工作原因,最近一直在使用Spring Web Flow,與之上幾個Web架構對比優點是:
1. 頁面流程明確, 除去JSF外,其它幾類架構要明確擷取頁面流程資訊並不容易. 對於企業開發來說,這點其實蠻重要的. 一般的互連網網站沒有特別的好處.
2. 不需要再寫Action等Web控制類. 雖然Struts2,JSF和Tapestry都是POJO了,但依然存在屬於Web層範疇的類,而Spring Web Flow不需要,邏輯寫在Flow檔案中, 直接存取Service對象,擷取Domain Model(我們還同時省略了VO). 當然這點可能有同學持反對意見.仁者見仁了!
3. Spring Web Flow提供單元測試能可以容易覆蓋頁面流程了.