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提供單元測試能可以容易覆蓋頁面流程了.