Struts，Sping和Spirng MVC等框架分析

Spring 及其優勢
大部分項目都少不了spring的身影，爲何你們對他如此青睞，並且對他的追捧絲毫沒有減退之勢呢

Spring是什麼：

Spring是一個輕量級的DI和AOP容器框架。

說它輕量級有一大部分緣由是相對與EJB的（雖然本人從沒有接觸過EJB的應用），重要的是，Spring是非侵入式的，基於spring開發的應用通常不依賴於spring的類。

DI：稱做依賴注入(Dependency Injection),和控制反轉一個概念，具體的講，當一個角色須要另一個角色協助的時候，在傳統的程序設計中，一般有調用者來建立被調用者的實例。可是在spring中建立被調用者將再也不有調用者完成，所以叫控制反轉。建立被調用對象有Spring來完成，在容器實例化對象的時候主動的將被調用者（或者說它的依賴對象）注入給調用對象，所以又叫依賴注入。

AOP：Spring對面向切面編程提供了強有力的支持，經過它讓咱們將業務邏輯從應用服務（如事務管理）中分離出來，實現了高內聚開發，應用對象只關注業務邏輯，再也不負責其它系統問題（如日誌、事務等）。Spring支持用戶自定義切面。
面向切面編程是面向對象編程的有力補充。面向對象編程將程序分紅各個層次的對象，面向切面的程序將運行過程分解成各個切面。AOP是從運行程序的角度去考慮程序的結構，提取業務處理過程的切面，OOP是靜態的抽象，AOP是動態的抽象，是對應用執行過程的步驟進行抽象，從而得到步驟之間的邏輯劃分。

容器：Spring是個容器，由於它包含而且管理應用對象的生命週期和配置。如對象的建立、銷燬、回調等。

框架：Spring做爲一個框架，提供了一些基礎功能，（如事務管理，持久層集成等），使開發人員更專一於開發應用邏輯。

看完了Spring是什麼，再來看看Spring有哪些優勢

1.使用Spring的IOC容器，將對象之間的依賴關係交給Spring，下降組件之間的耦合性，讓咱們更專一於應用邏輯

2.能夠提供衆多服務，事務管理，WS等。

3.AOP的很好支持，方便麪向切面編程。

4.對主流的框架提供了很好的集成支持，如hibernate,Struts2,JPA等

5.Spring DI機制下降了業務對象替換的複雜性。

6.Spring屬於低侵入，代碼污染極低。

7.Spring的高度可開放性，並不強制依賴於Spring，開發者能夠自由選擇Spring部分或所有

Struts2的優勢
Struts2 是一個至關強大的Java Web開源框架，是一個基於POJO的Action的MVC Web框架。它基於當年的Webwork和XWork框架，繼承其優勢，同時作了至關的改進。Struts2如今在Java Web開發界的地位能夠說是大紅大紫，從開發人員的角度來分析，Struts2之因此可以如此的深刻開發人員之心，與其優良的設計是分不開的。

一、Struts2基於MVC架構,框架結構清晰，開發流程一目瞭然，開發人員能夠很好的掌控開發的過程。

我在項目開發過程當中，一個具體的功能的開發流程是：拿到一個具體的功能需求文檔和設計好的前臺界面（在開發中我不負責設計頁面），分析須要從前臺傳遞哪些參數，肯定參數的變量名稱，在Action中設置相應的變量，這些參數在前臺如何顯示，並將頁面上的一些控件適當使用Struts2提供的服務器端控件來代替，編寫Action對應的方法來完成業務邏輯，最後，作一些與配置文件相關的設置。固然實際的開發比這個過程要複雜，涉及到數據庫，驗證，異常等處理。可是使用Struts2進行開發，你的關注點絕大部分是在如何實現業務邏輯上，開發過程十分清晰明瞭。

二、使用OGNL進行參數傳遞。
OGNL提供了在Struts2裏訪問各類做用域中的數據的簡單方式，你能夠方便的獲取Request，Attribute，Application，Session，Parameters中的數據。大大簡化了開發人員在獲取這些數據時的代碼量。

三、強大的攔截器
Struts2 的攔截器是一個Action級別的AOP，Struts2中的許多特性都是經過攔截器來實現的，例如異常處理，文件上傳，驗證等。攔截器是可配置與重用的，能夠將一些通用的功能如：登陸驗證，權限驗證等置於攔截器中以完成一些Java Web項目中比較通用的功能。在我實現的的一Web項目中，就是使用Struts2的攔截器來完成了系統中的權限驗證功能。

四、易於測試
Struts2的Action都是簡單的POJO，這樣能夠方便的對Struts2的Action編寫測試用例，大大方便了Java Web項目的測試。

五、易於擴展的插件機制
在Struts2添加擴展是一件愉快而輕鬆的事情，只須要將所須要的Jar包放到WEB-INF/lib文件夾中，在struts.xml中做一些簡單的設置就能夠實現擴展。經常使用的Struts2的擴展能夠經過這個連接找到：
http://cwiki.apache.org/S2PLUGINS/home.html

六、模塊化
Struts2已經把模塊化做爲了體系架構中的基本思想，能夠經過三種方法來將應用程序模塊化：
將配置信息拆分紅多個文件
把自包含的應用模塊建立爲插件
建立新的框架特性，即將與特定應用無關的新功能組織成插件，以添加到多個應用中去。

七、全局結果與聲明式異常
爲應用程序添加全局的Result，和在配置文件中對異常進行處理，這樣當處理過程當中出現指定異常時，能夠跳轉到特定頁面，這一功能十分實用。

Spring MVC和Struts2的比較的優勢
咱們用struts2時採用的傳統的配置文件的方式，並無使用傳說中的0配置。spring3 mvc能夠認爲已經100%零配置了（除了配置spring mvc-servlet.xml外）。

Spring MVC和Struts2的區別：

機制：spring mvc的入口是servlet，而struts2是filter（這裏要指出，filter和servlet是不一樣的。之前認爲filter是 servlet的一種特殊），這樣就致使了兩者的機制不一樣，這裏就牽涉到servlet和filter的區別了。

性能：spring會稍微比struts快。spring mvc是基於方法的設計，而sturts是基於類，每次發一次請求都會實例一個action，每一個action都會被注入屬性，而spring基於方法，粒度更細，但要當心把握像在servlet控制數據同樣。spring3 mvc是方法級別的攔截，攔截到方法後根據參數上的註解，把request數據注入進去，在spring3 mvc中，一個方法對應一個request上下文。而struts2框架是類級別的攔截，每次來了請求就建立一個Action，而後調用setter getter方法把request中的數據注入；struts2其實是經過setter getter方法與request打交道的；struts2中，一個Action對象對應一個request上下文。

參數傳遞：struts是在接受參數的時候，能夠用屬性來接受參數，這就說明參數是讓多個方法共享的。

設計思想上：struts更加符合oop的編程思想， spring就比較謹慎，在servlet上擴展。

intercepter的實現機制：struts有以本身的interceptor機制，spring mvc用的是獨立的AOP方式。這樣致使struts的配置文件量仍是比spring mvc大，雖然struts的配置能繼承，因此我以爲論使用上來說，spring mvc使用更加簡潔，開發效率Spring MVC確實比struts2高。spring mvc是方法級別的攔截，一個方法對應一個request上下文，而方法同時又跟一個url對應，因此說從架構自己上spring3 mvc就容易實現restful url。struts2是類級別的攔截，一個類對應一個request上下文；實現restful url要費勁，由於struts2 action的一個方法能夠對應一個url；而其類屬性卻被全部方法共享，這也就沒法用註解或其餘方式標識其所屬方法了。spring3 mvc的方法之間基本上獨立的，獨享request response數據，請求數據經過參數獲取，處理結果經過ModelMap交回給框架方法之間不共享變量，而struts2搞的就比較亂，雖然方法之間也是獨立的，但其全部Action變量是共享的，這不會影響程序運行，卻給咱們編碼，讀程序時帶來麻煩。

另外，spring3 mvc的驗證也是一個亮點，支持JSR303，處理ajax的請求更是方便，只需一個註解@ResponseBody ，而後直接返回響應文本便可。送上一段代碼：

[java] view plain copy
在CODE上查看代碼片派生到個人代碼片

 
 
 
 

  
  
  
  
1
  
  
  
  
2
  
  
  
  
3
  
  
  
  
4
  
  
  
  
5
  
  
  
  
6
  
  
  
  
7
  
  
  
  
8
  
  
  
  
9
  
  
  
  
10
  
  
  
  
11
  
  
  
  
12
  
  
  
  
13
  
  
  
  
14
  
  
  
  
15
 
 
 
 
@RequestMapping(value=「/whitelists」)  
        public String index(ModelMap map) {  
        Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId());  
        List groupList = groupManager.findAllGroup(account.getId());  
        map.put(「account」, account);  
        map.put(「groupList」, groupList);  
        return 「/group/group-index」;  
        }  
        // @ResponseBody ajax響應，處理Ajax請求也很方便 
        @RequestMapping(value=「/whitelist/{whiteListId}/del」)  
        @ResponseBody  
        public String delete(@PathVariable Integer whiteListId) {  
        whiteListManager.deleteWhiteList(whiteListId);  
        return 「success」;  
        }

struts1與struts2本質區別 1 在Action實現類方面的對比：Struts 1要求Action類繼續一個抽象基類；Struts 1的一個具體問題是使用抽象類編程而不是接口。Struts 2 Action類能夠實現一個Action接口，也能夠實現其餘接口，使可選和定製的服務成爲可能。Struts 2提供一個ActionSupport基類去實現經常使用的接口。即便Action接口不是必須實現的，只有一個包含execute方法的POJO類均可以用 做Struts 2的Action。 2 線程模式方面的對比：Struts 1 Action是單例模式而且必須是線程安全的，由於僅有Action的一個實例來處理全部的請求。單例策略限制了Struts 1 Action能作的事，而且要在開發時非凡當心。Action資源必須是線程安全的或同步的；Struts 2 Action對象爲每個請求產生一個實例，所以沒有線程安全問題。 3 Servlet依靠方面的對比：Struts 1 Action依靠於Servlet API，由於Struts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action再也不依靠於Serzvlet API，從而答應Action脫離Web容器運行，從而下降了測試Action的難度。 固然，假如Action須要直接訪問HttpServletRequest和HttpServletResponse參數，Struts 2 Action仍然能夠訪問它們。可是，大部分時候，Action都無需直接訪問HttpServetRequest和 HttpServletResponse，從而給開發者更多靈活的選擇。 4 可測性方面的對比：測試Struts 1 Action的一個主要問題是execute方法依靠於Servlet API，這使得Action的測試要依靠於Web容器。爲了脫離Web容器測試Struts 1的Action，必須藉助於第三方擴展：Struts TestCase，該擴展下包含了系列的Mock對象（模擬了HttpServetRequest和HttpServletResponse對象），從而 能夠脫離Web容器測試Struts 1的Action類。Struts 2 Action能夠經過初始化、設置屬性、調用方法來測試。 5 封裝請求參數的對比：Struts 1使用ActionForm對象封裝用戶的請求參數，全部的ActionForm必須繼續一個基類：ActionForm。普通的JavaBean不能用 做ActionForm，所以，開發者必須建立大量的ActionForm類封裝用戶請求參數。雖然Struts 1提供了動態ActionForm來簡化ActionForm的開發，但依然須要在配置文件中定義ActionForm；Struts 2直接使用Action屬性來封裝用戶請求屬性，避免了開發者須要大量開發ActionForm類的煩瑣，實際上，這些屬性還能夠是包含子屬性的Rich 對象類型。假如開發者依然懷念Struts 1 ActionForm的模式，Struts 2提供了ModelDriven模式，可讓開發者使用單獨的Model對象來封裝用戶請求參數，但該Model對象無需繼續任何Struts 2基類，是一個POJO，從而下降了代碼污染。 6 表達式語言方面的對比：Struts 1整合了JSTL，所以可使用JSTL表達式語言。這種表達式語言有基本對象圖遍歷，但在對集合和索引屬性的支持上則功能不強；Struts 2可使用JSTL，但它整合了一種更強大和靈活的表達式語言：OGNL（Object Graph Notation Language），所以，Struts 2下的表達式語言功能更增強大。 7 綁定值到視圖的對比：Struts 1使用標準JSP機制把對象綁定到視圖頁面；Struts 2使用「ValueStack」技術，使標籤庫可以訪問值，而不須要把對象和視圖頁面綁定在一塊兒。 8 類型轉換的對比：Struts 1 ActionForm 屬性一般都是String類型。Struts 1使用Commons-Beanutils進行類型轉換，每一個類一個轉換器，轉換器是不可配置的；Struts 2使用OGNL進行類型轉換，支持基本數據類型和經常使用對象之間的轉換。 9 數據校驗的對比：Struts 1支持在ActionForm重寫validate方法中手動校驗，或者經過整合Commons alidator框架來完成數據校驗。Struts 2支持經過重寫validate方法進行校驗，也支持整合XWork校驗框架進行校驗。 10 Action執行控制的對比：Struts 1支持每個模塊對應一個請求處理（即生命週期的概念），可是模塊中的全部Action必須共享相同的生命週期。Struts 2支持經過攔截器堆棧（Interceptor Stacks）爲每個Action建立不一樣的生命週期。開發者能夠根據須要建立相應堆棧，從而和不一樣的Action一塊兒使用。 Hibernate優勢 (1) 對象/關係數據庫映射(ORM) 它使用時只須要操縱對象，使開發更對象化，拋棄了數據庫中心的思想，徹底的面向對象思想 (2) 透明持久化(persistent) 帶有持久化狀態的、具備業務功能的單線程對象，此對象生存期很短。這些對象多是普通的JavaBeans/POJO，這個對象沒有實現第三方框架 或者接口，惟一特殊的是他們正與（僅僅一個）Session相關聯。一旦這個Session被關閉，這些對象就會脫離持久化狀態，這樣就可被應用程序的任 何層自由使用。（例如，用做跟表示層打交道的數據傳輸對象。） (3) 事務Transaction(org.hibernate.Transaction) 應用程序用來指定原子操做單元範圍的對象，它是單線程的，生命週期很短。它經過抽象將應用從底層具體的JDBC、JTA以及CORBA事務隔離 開。某些狀況下，一個Session以內可能包含多個Transaction對象。儘管是否使用該對象是可選的，但不管是使用底層的API仍是使用 Transaction對象，事務邊界的開啓與關閉是必不可少的。 (4) 它沒有侵入性，即所謂的輕量級框架 (5) 移植性會很好 (6) 緩存機制，提供一級緩存和二級緩存 (7) 簡潔的HQL編程 Hibernate缺點 (1) Hibernate在批量數據處理時有弱勢 (2) 針對單一對象簡單的增刪查改，適合於Hibernate,而對於批量的修改，刪除，不適合用Hibernate,這也是OR框架的弱點；要使用數據庫的特定優化機制的時候，不適合用Hibernate Hibernate和iBATIS 優缺點比較 （注意:iBATIS 是MyBATIS的前生，也就是1.0版本） Hibernate的特色： Hibernate功能強大，數據庫無關性好，O/R映射能力強， Hibernate對數據庫結構提供了較爲完整的封裝，Hibernate的O/R Mapping實現了POJO 和數據庫表之間的映射，以及SQL 的自動生成和執行。程序員每每只需定義好了POJO 到數據庫表的映射關係，便可經過Hibernate 提供的方法完成持久層操做。程序員甚至不須要對SQL 的熟練掌握， Hibernate/OJB 會根據制定的存儲邏輯，自動生成對應的SQL 並調用JDBC 接口加以執行。Hibernate的缺點就是學習門檻不低，要精通門檻更高，並且怎麼設計O/R映射，在性能和對象模型之間如何權衡取得平衡，以及怎樣用 好Hibernate方面須要你的經驗和能力都很強才行，可是Hibernate如今已是主流O/R Mapping框架，從文檔的豐富性，產品的完善性，版本的開發速度都要強於iBATIS。 iBATIS的特色： iBATIS入門簡單， 即學即用，提供了數據庫查詢的自動對象綁定功能，並且延續了很好的SQL使用經驗，對於沒有那麼高的對象模型要求的項目來講，至關完美。iBATIS的缺 點就是框架仍是比較簡陋，功能尚有缺失，雖然簡化了數據綁定代碼，可是整個底層數據庫查詢實際仍是要本身寫的，工做量也比較大，並且不太容易適應快速數據 庫修改。當系統屬於二次開發,沒法對數據庫結構作到控制和修改,那iBATIS的靈活性將比Hibernate更適合。系統數據處理量巨大，性能要求極爲 苛刻，這每每意味着咱們必須經過通過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。在這種狀況下iBATIS會有更好的可控性和表現。 對於實際的開發進行的比較： 1． iBATIS須要手寫sql語句，也能夠生成一部分，Hibernate則基本上能夠自動生成，偶爾會寫一些Hql。一樣的需求,iBATIS的工做量比 Hibernate要大不少。相似的，若是涉及到數據庫字段的修改，Hibernate修改的地方不多，而iBATIS要把那些sql mapping的地方一一修改。 2. iBatis 能夠進行細粒度的優化 比 如說我有一個表，這個表有幾個或者幾十個字段，我須要更新其中的一個字段，iBatis 很簡單，執行一個sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 可是用 Hibernate 的話就比較麻煩了,缺省的狀況下 hibernate 會更新全部字段。 固然我記得 hibernate 有一個選項能夠控制只保存修改過的字段，可是我不太肯定這個功能的負面效果。 例 如：我須要列出一個表的部份內容，用 iBatis 的時候，這裏面的好處是能夠少從數據庫讀不少數據，節省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE …通常狀況下Hibernate 會把全部的字段都選出來。比 如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我爲何要把他們也選出來呢？用 hibernate 的話，你又不能把這兩個不須要的字段設置爲lazy load，由於還有不少地方須要一次把整個 domain object 加載出來。這個時候就能顯現出ibatis 的好處了。若是我須要更新一條記錄（一個對象），若是使用 hibernate，須要現把對象 select 出來，而後再作 update。這對數據庫來講就是兩條sql。而iBatis只須要一條update的sql就能夠了。減小一次與數據庫的交互，對於性能的提高是很是重 要。 3. 開發方面： 開發效率上，我以爲二者應該差很少。可維護性方面，我 以爲 iBatis 更好一些。由於 iBatis 的 sql 都保存到單獨的文件中。而 Hibernate 在有些狀況下可能會在 java 代碼中保sql/hql。相對Hibernate「O/R」而言，iBATIS 是一種「Sql Mapping」的ORM實現。（iBatis 是將sql寫在配置文件中的，而hibernate是本身生成的） 而iBATIS 的着力點，則在於POJO 與SQL之間的映射關係。也就是說，iBATIS並不會爲程序員在運行期自動生成SQL 執行。具體的SQL 須要程序員編寫，而後經過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。使用iBATIS 提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的Java對象，這一層與經過Hibernate 實現ORM 而言基本一致，而對於具體的數據操做，Hibernate會自動生成SQL 語句，而iBATIS 則要求開發者編寫具體的SQL 語句。相對Hibernate而言，iBATIS 以SQL開發的工做量和數據庫移植性上的讓步，爲系統設計提供了更大的自由空間。 4. 運行效率 在不考慮 cache 的狀況下，iBatis 應該會比hibernate 快一些或者不少。 Spring 框架的優缺點 Spring的優點不言而喻： 　 1. 提供了一種管理對象的方法，能夠把中間層對象有效地組織起來。一個完美的框架「黏合劑」。 　 2. 採用了分層結構，能夠增量引入到項目中。 　 3. 有利於面向接口編程習慣的養成。 　 4. 目的之一是爲了寫出易於測試的代碼。 　 5. 非侵入性，應用程序對Spring API的依賴能夠減至最小限度。 　 6. 一致的數據訪問介面。 　 6. 一個輕量級的架構解決方案 缺點也顯而易見 1. 中斷了應用程序的邏輯，使代碼變得不完整，不直觀。此時單從Source沒法徹底把握應用的全部行爲。 　2. 將本來應該代碼化的邏輯配置化，增長了出錯的機會以及額外的負擔。 3. 時光倒退，失去了IDE的支持。在目前IDE功能日益強大的時代，以往代碼重構等讓人頭痛的舉動愈來愈容易。並且IDE還提供了諸多強大的輔助功能，使得 編程的門檻下降不少。一般來講，維護代碼要比維護配置文件，或者配置文件+代碼的混合體要容易的多。 　4. 調試階段不直觀，後期的bug對應階段，不容易判斷問題所在。 經典架構S（Struts）SH的優缺點 Struts、Spring、Hibernate能流行這麼多年經久不衰，天然有它的道理。J2EE最早出現的時候，咱們通常是採用 JSP+Servlet+JavaBean+EJB的架構，尤爲是1998年～2000年這段時間，互聯網的泡沫從興起到破裂，其波瀾壯闊程度，絲絕不亞 於2008年開始的此次經濟危機，在那個年代，是否掌握EJB開發技術將直接決定你的薪水可否翻一倍或者幾倍。不過，Spring的做者Rod Johnson在2002年根據多年經驗撰寫了《Expert o-ne-on-One J2EE Design and Development》，其後又發表了著名的《Expert o-ne-on-one J2EE Development without EJB》一書，則完全地改變了傳統的J2EE一統天下的開發架構，基於Struts+Hibernate+Spring的J2EE架構也逐漸獲得人們的認 可，甚至在大型的項目架構中也逐漸開始應用。下面咱們分別說說Spring、Struts和Hibernate的優缺點。 Spring 是一個開源框架，是爲了解決企業應用程序開發複雜性而建立的。框架的主要優點之一就是其分層架構，使得每一個層之間和類與類之間的關係，由原來的強綁定與強 耦合轉變爲不綁定和鬆耦合，直接面向接口編程，把設計與實現相分離的原則發揮到極致，對於單元測試也產生了很深遠的影響。在Spring出現以前，若是某 個模塊沒有完成，作單獨模塊的單元測試仍是很困難的。Spring同時也是 J2EE 應用程序開發的集成框架，由於J2EE是講究分層理念的，Spring使得J2EE每一個層之間的模塊職能更加清晰。 不過，對於大型項目的開發，Spring使得原來難以維護的類與類之間的強耦合關係，轉變爲更加難以維護的XML文件配置，這個工做量也是很是巨大 的，並且更容易出錯。並且，隨着每一個應用 模塊的升級，這些模塊之間的版本，也不會是同步更新的，對於同一個公共組件，有的模塊用的多是1.0版本，而另 外一個功能模塊用的多是2.0版本，可怕的是1.0版本和2.0版本之間，可能還不兼容，Spring對於這些需求，就無能爲力了。因此，有人說 Spring不適合大型項目開發，也是有必定道理的。最近Spring也加入了OSGI標準的實現，也是爲了解決不一樣版本之間同時存在的這些問題。不過， 隨着Spring加入的功能愈來愈多，Spring也就失去了輕量開源框架的特色，變得愈來愈笨重。 雖然Spring如今也支持了所謂的免配置，能夠經過@Autowired標籤自行綁定，還能夠經過 設置自動綁定加載全部的Hibernate對象，可是若是這些上百個或者數十個中的任何一個Entity對象加載失敗，則整個Spring服務就啓動不起 來了，這與難於部署的EJB有啥區別呢？並且，使人好笑的是，因爲使用了@Autowired標籤，至關一部分開發人員再也不面向接口編程了，對於 Class A的實例，美其名曰由Spring自行綁定，接口也好，實際實現類也好，就在Spring配置一下就能夠了。而Spring最核心的就是面向接口編程和 IOC，沒有了面向接口編程，用一個 A a=new A() 來實例化一個Class，有什麼不能夠呢？少寫了一行代碼，引入了一個重量級的Spring，究竟爲啥使用Spring呢？ 對於Hibernate的流行，則是因爲開發人員和客戶，對於Entity EJB（實體EJB）臃腫的身材及部署的困難，是在極度失望情緒下形成的。既然是輕量級解決方案，那麼分佈式就不是可選項，沒有分佈式，那麼EJB就無用 武之地了。話又說回來了，Rod Johnson前些年就由於強調絕大部分企業應用是不須要分佈式的，從而推出了本身輕量級的Spring解決方案。可是最近一年，隨着雲計算架構的興起， 架構是否支持分佈式，又是必選項了。技術架構的選型，就跟法國巴黎流行時裝同樣，今年流行短袖，明年流行下襬，真是典型的十年河東，十年河西。因此，像 SOA、雲計算、SaaS、物聯網這些大名詞，不只會給客戶帶來很大的困惑，一樣也會給程序員、系統分析師、系統架構師、技術總監帶來困惑。從確定到否 定，再到自我否認，真是符合大天然螺旋式上升的發展規律。 而對於Struts，它一經推出，幾乎戰勝了當時的全部競爭對手。Struts的偉大之處，在於它對網頁數據的動態綁定。雖然數據綁定不是一個新名 詞，微軟在1991年推出Visual Basic1.0的時候，就創造性地發明了讓VB程序員又愛又恨的數據綁定，可是對於Web 編程，Struts也仍是把數據綁定首次應用到了Web編程上。它可以讓人們用Set和Get的形式取得網頁數據，而不是單一的黑盒式的 request.getParameter()，從而使得網頁數據取值進入面向對象（OO）化時代。 Struts、Hibernate以及Spring自己都是製做精良的框架，可是對於本身產品和項目的應用，一經整合在一塊兒，卻不必定很適用。好比 說，對於數據庫相關的MIS（管理信息系統）系統中，增長、修改、刪除、查詢功能是最基本、最多見、必不可少的。對於這些最基本的功能，不一樣的架構師，則 會作出不一樣的選擇。有的架構師，選擇了自動生成的理念，作一個代碼自動生成器，設計好數據庫表結構，單擊一個腳本，或者用Eclipse插件的形式，作個 圖形化生成界面，自動生成SSH框架，完成數據庫的增長、修改、刪除、查詢操做。這麼作的好處是數據庫修改了，代碼自動生成就能夠了，使得程序員不用再維 護這些無聊的代碼。不過缺陷也是致命的，一是隨着Struts、Hibernate、Spring的升級，這個工具也不得不跟着升級，而作這個工具的程序 員，可能早就離開公司了，後續版本沒法維護；二是若是有的業務邏輯跟這些生成的代碼有交叉，數據庫變動後，代碼也沒法再次生成了。三是公司的系統架構，則 被嚴重限制在SSH架構基礎上，再也沒法改變。有人會問：即便限制在這三種架構上，有何很差嗎？假設有客戶問，你的框架支持雲計算嗎？你總不能說」因爲 Struts、Hibernate、Spring 不支持雲計算架構，因此我也不支持」以此取得客戶諒解吧。所以，依賴於第三方架構的產品體系架構，隨着時間的推移，受到的限制會愈來愈大。