[[274718]]

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之所以能夠如此的深入開發人員之心，與其優良的設計是分不開的。

1、Struts2基于MVC架構,框架結構清晰，開發流程一目了然，開發人員可以很好的掌控開發的過程。

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

2、使用OGNL進行參數傳遞。

OGNL提供了在Struts2里訪問各種作用域中的數據的簡單方式，你可以方便的獲取Request，Attribute，Application，Session，Parameters中的數據。大大簡化了開發人員在獲取這些數據時的代碼量。

3、強大的攔截器

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

4、易于測試

Struts2的Action都是簡單的POJO，這樣可以方便的對Struts2的Action編寫測試用例，大大方便了Java Web項目的測試。

5、易于擴展的插件機制

在Struts2添加擴展是一件愉快而輕松的事情，只需要將所需要的Jar包放到WEB-INF/lib文件夾中，在struts.xml中作一些簡單的設置就可以實現擴展。常用的Struts2的擴展可以通過這個鏈接找到：

http://cwiki.apache.org/S2PLUGINS/home.html

6、模塊化

Struts2已經把模塊化作為了體系架構中的基本思想，可以通過三種方法來將應用程序模塊化：

將配置信息拆分成多個文件

把自包含的應用模塊創建為插件

創建新的框架特性，即將與特定應用無關的新功能組織成插件，以添加到多個應用中去。

7、全局結果與聲明式異常

為應用程序添加全局的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上查看代碼片派生到我的代碼片

@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 不支持云計算架構，所以我也不支持”以此取得客戶諒解吧。因此，依賴于第三方架構的產品體系架構，隨著時間的推移，受到的限制會越來越大。