1) 在Action實(shí)現(xiàn)類方面的對比:Struts 1要求Action類繼承一個(gè)抽象基類;Struts 1的一個(gè)具體問題是使用抽象類編程而不是接口。Struts 2 Action類可以實(shí)現(xiàn)一個(gè)Action接口,也可以實(shí)現(xiàn)其他接口,使可選和定制的服務(wù)成為可能。Struts 2提供一個(gè)ActionSupport基類去實(shí)現(xiàn)常用的接口。即使Action接口不是必須實(shí)現(xiàn)的,只有一個(gè)包含execute方法的POJO類都可以用作Struts 2的Action。
2) 線程模式方面的對比:Struts 1 Action是單例模式并且必須是線程安全的,因?yàn)閮H有Action的一個(gè)實(shí)例來處理所有的請求。單例策略限制了Struts 1 Action能做的事,并且要在開發(fā)時(shí)特別小心。Action資源必須是線程安全的或同步的;Struts 2 Action對象為每一個(gè)請求產(chǎn)生一個(gè)實(shí)例,因此沒有線程安全問題。
3) Servlet依賴方面的對比:Struts 1 Action依賴于Servlet API,因?yàn)镾truts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依賴于Servlet API,從而允許Action脫離Web容器運(yùn)行,從而降低了測試Action的難度。 當(dāng)然,如果Action需要直接訪問HttpServletRequest和HttpServletResponse參數(shù),Struts 2 Action仍然可以訪問它們。但是,大部分時(shí)候,Action都無需直接訪問HttpServetRequest和HttpServletResponse,從而給開發(fā)者更多靈活的選擇。
4) 可測性方面的對比:測試Struts 1 Action的一個(gè)主要問題是execute方法依賴于Servlet API,這使得Action的測試要依賴于Web容器。為了脫離Web容器測試Struts 1的Action,必須借助于第三方擴(kuò)展:Struts TestCase,該擴(kuò)展下包含了系列的Mock對象(模擬了HttpServetRequest和HttpServletResponse對象),從而可以脫離Web容器測試Struts 1的Action類。Struts 2 Action可以通過初始化、設(shè)置屬性、調(diào)用方法來測試。
5) 封裝請求參數(shù)的對比:Struts 1使用ActionForm對象封裝用戶的請求參數(shù),所有的ActionForm必須繼承一個(gè)基類:ActionForm。普通的JavaBean不能用作ActionForm,因此,開發(fā)者必須創(chuàng)建大量的ActionForm類封裝用戶請求參數(shù)。雖然Struts 1提供了動(dòng)態(tài)ActionForm來簡化ActionForm的開發(fā),但依然需要在配置文件中定義ActionForm;Struts 2直接使用Action屬性來封裝用戶請求屬性,避免了開發(fā)者需要大量開發(fā)ActionForm類的煩瑣,實(shí)際上,這些屬性還可以是包含子屬性的Rich對象類型。如果開發(fā)者依然懷念Struts 1 ActionForm的模式,Struts 2提供了ModelDriven模式,可以讓開發(fā)者使用單獨(dú)的Model對象來封裝用戶請求參數(shù),但該Model對象無需繼承任何Struts 2基類,是一個(gè)POJO,從而降低了代碼污染。
6) 表達(dá)式語言方面的對比:Struts 1整合了JSTL,因此可以使用JSTL表達(dá)式語言。這種表達(dá)式語言有基本對象圖遍歷,但在對集合和索引屬性的支持上則功能不強(qiáng);Struts 2可以使用JSTL,但它整合了一種更強(qiáng)大和靈活的表達(dá)式語言:OGNL(Object Graph Notation Language),因此,Struts 2下的表達(dá)式語言功能更加強(qiáng)大。
7) — 綁定值到視圖的對比:Struts 1使用標(biāo)準(zhǔn)JSP機(jī)制把對象綁定到視圖頁面;Struts 2使用“ValueStack”技術(shù),使標(biāo)簽庫能夠訪問值,而不需要把對象和視圖頁面綁定在一起。
8) 類型轉(zhuǎn)換的對比:Struts 1 ActionForm 屬性通常都是String類型。Struts 1使用Commons-Beanutils進(jìn)行類型轉(zhuǎn)換,每個(gè)類一個(gè)轉(zhuǎn)換器,轉(zhuǎn)換器是不可配置的;Struts 2使用OGNL進(jìn)行類型轉(zhuǎn)換,支持基本數(shù)據(jù)類型和常用對象之間的轉(zhuǎn)換。
9) 數(shù)據(jù)校驗(yàn)的對比:Struts 1支持在ActionForm重寫validate方法中手動(dòng)校驗(yàn),或者通過整合Commons alidator框架來完成數(shù)據(jù)校驗(yàn)。Struts 2支持通過重寫validate方法進(jìn)行校驗(yàn),也支持整合XWork校驗(yàn)框架進(jìn)行校驗(yàn)。
10) Action執(zhí)行控制的對比:Struts 1支持每一個(gè)模塊對應(yīng)一個(gè)請求處理(即生命周期的概念),但是模塊中的所有Action必須共享相同的生命周期。Struts 2支持通過攔截器堆棧(Interceptor Stacks)為每一個(gè)Action創(chuàng)建不同的生命周期。開發(fā)者可以根據(jù)需要?jiǎng)?chuàng)建相應(yīng)堆棧,從而和不同的Action一起使用。
11) 捕獲輸入:Struts1 使用ActionForm對象捕獲輸入。所有的ActionForm必須繼承一個(gè)基類。因?yàn)槠渌鸍avaBean不能用作ActionForm,開發(fā)者經(jīng)常創(chuàng)建多余的類捕獲輸入。動(dòng)態(tài)Bean(DynaBeans)可以作為創(chuàng)建傳統(tǒng)ActionForm的選擇,但是,開發(fā)者可能是在重新描述(創(chuàng)建)已經(jīng)存在的JavaBean(仍然會(huì)導(dǎo)致有冗余的javabean)。Struts 2直接使用Action屬性作為輸入屬性,消除了對第二個(gè)輸入對象的需求。輸入屬性可能是有自己(子)屬性的rich對象類型。Action屬性能夠通過 web頁面上的taglibs訪問。Struts2也支持ActionForm模式。rich對象類型,包括業(yè)務(wù)對象,能夠用作輸入/輸出對象。這種 ModelDriven 特性簡化了taglib對POJO輸入對象的引用。
2) 線程模式方面的對比:Struts 1 Action是單例模式并且必須是線程安全的,因?yàn)閮H有Action的一個(gè)實(shí)例來處理所有的請求。單例策略限制了Struts 1 Action能做的事,并且要在開發(fā)時(shí)特別小心。Action資源必須是線程安全的或同步的;Struts 2 Action對象為每一個(gè)請求產(chǎn)生一個(gè)實(shí)例,因此沒有線程安全問題。
3) Servlet依賴方面的對比:Struts 1 Action依賴于Servlet API,因?yàn)镾truts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依賴于Servlet API,從而允許Action脫離Web容器運(yùn)行,從而降低了測試Action的難度。 當(dāng)然,如果Action需要直接訪問HttpServletRequest和HttpServletResponse參數(shù),Struts 2 Action仍然可以訪問它們。但是,大部分時(shí)候,Action都無需直接訪問HttpServetRequest和HttpServletResponse,從而給開發(fā)者更多靈活的選擇。
4) 可測性方面的對比:測試Struts 1 Action的一個(gè)主要問題是execute方法依賴于Servlet API,這使得Action的測試要依賴于Web容器。為了脫離Web容器測試Struts 1的Action,必須借助于第三方擴(kuò)展:Struts TestCase,該擴(kuò)展下包含了系列的Mock對象(模擬了HttpServetRequest和HttpServletResponse對象),從而可以脫離Web容器測試Struts 1的Action類。Struts 2 Action可以通過初始化、設(shè)置屬性、調(diào)用方法來測試。
5) 封裝請求參數(shù)的對比:Struts 1使用ActionForm對象封裝用戶的請求參數(shù),所有的ActionForm必須繼承一個(gè)基類:ActionForm。普通的JavaBean不能用作ActionForm,因此,開發(fā)者必須創(chuàng)建大量的ActionForm類封裝用戶請求參數(shù)。雖然Struts 1提供了動(dòng)態(tài)ActionForm來簡化ActionForm的開發(fā),但依然需要在配置文件中定義ActionForm;Struts 2直接使用Action屬性來封裝用戶請求屬性,避免了開發(fā)者需要大量開發(fā)ActionForm類的煩瑣,實(shí)際上,這些屬性還可以是包含子屬性的Rich對象類型。如果開發(fā)者依然懷念Struts 1 ActionForm的模式,Struts 2提供了ModelDriven模式,可以讓開發(fā)者使用單獨(dú)的Model對象來封裝用戶請求參數(shù),但該Model對象無需繼承任何Struts 2基類,是一個(gè)POJO,從而降低了代碼污染。
6) 表達(dá)式語言方面的對比:Struts 1整合了JSTL,因此可以使用JSTL表達(dá)式語言。這種表達(dá)式語言有基本對象圖遍歷,但在對集合和索引屬性的支持上則功能不強(qiáng);Struts 2可以使用JSTL,但它整合了一種更強(qiáng)大和靈活的表達(dá)式語言:OGNL(Object Graph Notation Language),因此,Struts 2下的表達(dá)式語言功能更加強(qiáng)大。
7) — 綁定值到視圖的對比:Struts 1使用標(biāo)準(zhǔn)JSP機(jī)制把對象綁定到視圖頁面;Struts 2使用“ValueStack”技術(shù),使標(biāo)簽庫能夠訪問值,而不需要把對象和視圖頁面綁定在一起。
8) 類型轉(zhuǎn)換的對比:Struts 1 ActionForm 屬性通常都是String類型。Struts 1使用Commons-Beanutils進(jìn)行類型轉(zhuǎn)換,每個(gè)類一個(gè)轉(zhuǎn)換器,轉(zhuǎn)換器是不可配置的;Struts 2使用OGNL進(jìn)行類型轉(zhuǎn)換,支持基本數(shù)據(jù)類型和常用對象之間的轉(zhuǎn)換。
9) 數(shù)據(jù)校驗(yàn)的對比:Struts 1支持在ActionForm重寫validate方法中手動(dòng)校驗(yàn),或者通過整合Commons alidator框架來完成數(shù)據(jù)校驗(yàn)。Struts 2支持通過重寫validate方法進(jìn)行校驗(yàn),也支持整合XWork校驗(yàn)框架進(jìn)行校驗(yàn)。
10) Action執(zhí)行控制的對比:Struts 1支持每一個(gè)模塊對應(yīng)一個(gè)請求處理(即生命周期的概念),但是模塊中的所有Action必須共享相同的生命周期。Struts 2支持通過攔截器堆棧(Interceptor Stacks)為每一個(gè)Action創(chuàng)建不同的生命周期。開發(fā)者可以根據(jù)需要?jiǎng)?chuàng)建相應(yīng)堆棧,從而和不同的Action一起使用。
11) 捕獲輸入:Struts1 使用ActionForm對象捕獲輸入。所有的ActionForm必須繼承一個(gè)基類。因?yàn)槠渌鸍avaBean不能用作ActionForm,開發(fā)者經(jīng)常創(chuàng)建多余的類捕獲輸入。動(dòng)態(tài)Bean(DynaBeans)可以作為創(chuàng)建傳統(tǒng)ActionForm的選擇,但是,開發(fā)者可能是在重新描述(創(chuàng)建)已經(jīng)存在的JavaBean(仍然會(huì)導(dǎo)致有冗余的javabean)。Struts 2直接使用Action屬性作為輸入屬性,消除了對第二個(gè)輸入對象的需求。輸入屬性可能是有自己(子)屬性的rich對象類型。Action屬性能夠通過 web頁面上的taglibs訪問。Struts2也支持ActionForm模式。rich對象類型,包括業(yè)務(wù)對象,能夠用作輸入/輸出對象。這種 ModelDriven 特性簡化了taglib對POJO輸入對象的引用。