開源的SSH框架優缺點分析

開源是3個框架共有的優勢

Struts2框架（MVC框架）的優勢以下：

1） 實現了MVC模式，層次結構清晰，使程序員只需關注業務邏輯的實現；

2） 豐富的標籤庫，大大提升了開發的效率；

3） Struts2提供豐富的攔截器實現

3） 經過配置文件，就能夠掌握整個系統各個部分之間的關係；

4） 異常處理機制，只需在配置文件中配置異常的映射，便可對異常作相應的處理；

Spring框架的優勢以下：

1） 無入侵性（在業務邏輯代碼中感受不到Spring框架的存在）；

2） 各個組件之間的耦合極爲鬆散；

3） 無需程序員本身實現singleton模式；

4） 經過AOP，能夠實現事務管理和日誌管理；

5） 整合其餘的框架，如：struts框架和hibernate框架；

Hibernate框架（ORM框架）的優勢以下：

1） 對象/關係數據庫映射（ORM）， 使用時只需操縱對象，使開發更加面向對象化；

2） 無入侵性；

3） 簡潔的HQL語句，減小了JDBC與SQL操做數據庫的代碼量；

4） 移植性好；

缺點以下：

1） 對批量更新，刪除的支持很差；

什麼是SSH2框架。好處在哪裏？

SSH2框架：

具體來講應該是：struts2.0+spring3.2+hirbnate2.5
典型的J2EE三層結構，分爲表現層、中間層（業務邏輯層）和數據服務層。三層體系將業務規則、數據訪問及合法性校驗等工做放在中間層處理。客戶端不直接與數據庫交互，而是經過組件與中間層創建鏈接，再由中間層與數據庫交互。

表現層是傳統的JSP技術，自1999年問世以來，通過多年的發展，其普遍的應用和穩定的表現，爲其做爲表現層技術打下了堅實的基礎。

中間層採用的是流行的Spring+Hibernate，爲了將控制層與業務邏輯層分離，又細分爲如下幾種。

Web層，就是MVC模式裏面的「C」（controller），負責控制業務邏輯層與表現層的交互，調用業務邏輯層，並將業務數據返回給表現層做組織表現，該系統的MVC框架採用Struts。

Service層（就是業務邏輯層），負責實現業務邏輯。業務邏輯層以DAO層爲基礎，經過對DAO組件的正面模式包裝，完成系統所要求的業務邏輯。

DAO層，負責與持久化對象交互。該層封裝了數據的增、刪、查、改的操做。

PO，持久化對象。經過實體關係映射工具將關係型數據庫的數據映射成對象，很方便地實現以面向對象方式操做數據庫，該系統採用Hibernate做爲ORM框架。

Spring的做用貫穿了整個中間層，將Web層、Service層、DAO層及PO無縫整合，其數據服務層用來存放數據。

一個良好的框架可讓開發人員減輕從新創建解決複雜問題方案的負擔和精力；它能夠被擴展以進行內部的定製化；而且有強大的用戶社區來支持它。框架一般能很好的解決一個問題。然而，你的應用是分層的，可能每個層都須要各自的框架。僅僅解決UI問題並不意味着你可以很好的將業務邏輯和持久性邏輯和UI 組件很好的耦合。



不能否認，對於簡單的應用，採用ASP或者PHP的開發效率比採用J2EE框架的開發效率要高。甚至有人會以爲：這種分層的結構，比通常採用JSP + Servlet的系統開發效率還要低。

筆者從一下幾個角度來闡述這個問題。

— 開發效率：軟件工程是個特殊的行業，不一樣於傳統的工業，例如電器、建築及汽車等行業。這些行業的產品一旦開發出來，交付用戶使用後將不多須要後續的維護。但軟件行業不一樣，軟件產品的後期運行維護是個巨大的工程，單純從前期開發時間上考慮其開發效率是不理智的，也是不公平的。衆所周知，對於傳統的ASP和 PHP等腳本站點技術，將整個站點的業務邏輯和表現邏輯都混雜在ASP或PHP頁面裏，從而致使頁面的可讀性至關差，可維護性很是低。即便須要簡單改變頁面的按鈕，也不得不打開頁面文件，冒着破壞系統的風險。但採用嚴格分層J2EE架構，則可徹底避免這個問題。對錶現層的修改即便發生錯誤，也絕對不會將錯誤擴展到業務邏輯層，更不會影響持久層。所以，採用J2EE分層架構，即便前期的開發效率稍微低一點，但也是值得的。

— 需求的變動：以筆者多年的開發經驗來看，不多有軟件產品的需求從一開始就徹底是固定的。客戶對軟件需求，是隨着軟件開發過程的深刻，不斷明晰起來的。所以，經常遇到軟件開發到必定程度時，因爲客戶對軟件需求發生了變化，使得軟件的實現不得不隨之改變。當軟件實現須要改變時，是否能夠儘量多地保留軟件的部分，儘量少地改變軟件的實現，從而知足客戶需求的變動？答案是——採用優秀的解耦架構。這種架構就是J2EE的分層架構，在優秀的分層架構裏，控制層依賴於業務邏輯層，但毫不與任何具體的業務邏輯組件耦合，只與接口耦合；一樣，業務邏輯層依賴於DAO層，也不會與任何具體的DAO組件耦合，而是面向接口編程。採用這種方式的軟件實現，即便軟件的部分發生改變，其餘部分也儘量不要改變。

注意：即便在傳統的硬件行業，也有大量的接口規範。例如PCI接口、顯卡或者網卡，只要其遵照PCI的規範，就能夠插入主板，與主板通訊。至於這塊卡內部的實現，不是主板所關心的，這也正是面向接口編程的好處。假如須要提升電腦的性能，須要更新顯卡，只要更換另外一塊PCI接口的顯卡，而不是將整臺電腦拋棄。若是一臺電腦不是採用各類接口組合在一塊兒，而是作成整塊，那將意味着即便只須要更新網卡，也要放棄整臺電腦。一樣，對於軟件中的一個個組件，當一個組件須要重構時，儘可能不會影響到其餘組件。實際上，這是最理想的狀況，即便採用目前最優秀的架構，也會有或多或少的影響，這也是軟件工程須要努力提升的地方。

技術的更新，系統重構：軟件行業的技術更新很快，雖然軟件行業的發展不快，但小範圍的技術更新特別快。一旦因爲客觀環境的變化，不得不更換技術時，如何保證系統的改變最小呢？答案仍是選擇優秀的架構。

在傳統的Model 1的程序結構中，只要有一點小的需求發生改變，將意味着放棄整個頁面。或者改寫。雖然前期的開發速度快，除非能夠保證之後永遠不會改變應用的結構，不然不要採用Model 1的結構。

採用Hibernate做爲持久層技術的最大的好處在於：能夠徹底以面向對象的方式進行系統分析、系統設計。

DAO模式須要爲每一個DAO組件編寫DAO接口，同時至少提供一個實現類，根據不一樣須要，可能有多個實現類。用Spring容器代替DAO工廠

一般狀況下，引入接口就不可避免須要引入工廠來負責DAO組件的生成。Spring實現了兩種基本模式：單態模式和工廠模式。而使用Spring能夠徹底避免使用工廠模式，由於Spring就是個功能很是強大的工廠。所以，徹底可讓Spring充當DAO工廠。

由Spring充當DAO工廠時，無須程序員本身實現工廠模式，只須要將DAO組件配置在Spring容器中，由ApplicationContext負責管理DAO組件的建立便可。藉助於Spring提供的依賴注入，其餘組件甚至不用訪問工廠，同樣能夠直接使用DAO實例。

優勢：
Struts跟Tomcat、Turbine等諸多Apache項目同樣，是開源軟件，這是它的一大優勢。使開發者能更深刻的瞭解其內部實現機制。
除此以外，Struts的優勢主要集中體如今兩個方面：Taglib和頁面導航。Taglib是Struts的標記庫，靈活動用，能大大提升開發效率。另外，就目前國內的JSP開發者而言，除了使用JSP自帶的經常使用標記外，不多開發本身的標記，或許Struts是一個很好的起點。
關於頁面導航，我認爲那將是從此的一個發展方向，事實上，這樣作，使系統的脈絡更加清晰。經過一個配置文件，便可把握整個系統各部分之間的聯繫，這對於後期的維護有着莫大的好處。尤爲是當另外一批開發者接手這個項目時，這種優點體現得更加明顯。
缺點：
Taglib是Struts的一大優點，但對於初學者而言，卻須要一個持續學習的過程，甚至還會打亂你網頁編寫的習慣，可是，當你習慣了它時，你會以爲它真的很棒。
Struts將MVC的Controller一分爲三，在得到結構更加清晰的同時，也增長了系統的複雜度。
Struts從產生到如今還不到半年，但已逐步愈來愈多運用於商業軟件。雖然它如今還有很多缺點，但它是一種很是優秀的J2EE MVC實現方式，若是你的系統準備採用J2EE MVC架構，那麼，不妨考慮一下Struts。

SSH2相比SSH1的不一樣就是前者使用了更方便、更安全的MVC框架Struts2.。。

SSH2的主要內容包括：Struts二、Hibernate、Spring

Struts2是優秀的MVC框架。。。

Hibernate是如今最好用的ORM框架。。。

Spring是如今使用最廣泛的Ioc容器。。。用來處理業務邏輯。

 

 

1.struts

struts框架具備組件的模塊化，靈活性和重用性的優勢，同時簡化了基於MVC的web應用程序的開發。

優勢：
Struts跟Tomcat、Turbine等諸多Apache項目同樣，是開源軟件，這是它的一大優勢。使開發者能更深刻的瞭解其內部實現機制。
除此以外，Struts的優勢主要集中體如今兩個方面：Taglib和頁面導航。Taglib是Struts的標記庫，靈活動用，能大大提升開發效率。另外，就目前國內的JSP開發者而言，除了使

用JSP自帶的經常使用標記外，不多開發本身的標記，或許Struts是一個很好的起點。
關於頁面導航，我認爲那將是從此的一個發展方向，事實上，這樣作，使系統的脈絡更加清晰。經過一個配置文件，便可把握整個系統各部分之間的聯繫，這對於後期的維護有着

莫大的好處。尤爲是當另外一批開發者接手這個項目時，這種優點體現得更加明顯。

另外，struts是業界"標準"（不少成功案例），學習資源豐富，HTML標籤很是優秀

缺點：
Taglib是Struts的一大優點，但對於初學者而言，卻須要一個持續學習的過程，甚至還會打亂你網頁編寫的習慣，可是，當你習慣了它時，你會以爲它真的很棒。
Struts將MVC的Controller一分爲三，在得到結構更加清晰的同時，也增長了系統的複雜度。
ActionForms使用不便、沒法進行單元測試（StrutsTestCase只能用於集成）

【IT168技術文檔】
Struts跟Tomcat、Turbine等諸多Apache項目同樣，是開源軟件，這是它的一大優勢。使開發者能更深刻的瞭解其內部實現機制。 Struts開放源碼框架的建立是爲了使開發者

在構建基於Java Servlet和JavaServer Pages（JSP）技術的Web應用時更加容易。Struts框架爲開放者提供了一個統一的標準框架，經過使用Struts做爲基礎，開發者可以更專一

於應用程序的商業邏輯。Struts框架自己是使用Java Servlet和JavaServer Pages技術的一種Model-View-Controller（MVC）實現.
具體來說,Struts的優勢有:

1. 實現MVC模式，結構清晰,使開發者只關注業務邏輯的實現.

2. 有豐富的tag能夠用 ,Struts的標記庫(Taglib)，如能靈活動用，則能大大提升開發效率。另外，就目前國內的JSP開發者而言，除了使用JSP自帶的經常使用標記外，不多開發

本身的標記，或許Struts是一個很好的起點。

3. 頁面導航.頁面導航將是從此的一個發展方向，事實上，這樣作，使系統的脈絡更加清晰。經過一個配置文件，便可把握整個系統各部分之間的聯繫，這對於後期的維護有

着莫大的好處。尤爲是當另外一批開發者接手這個項目時，這種優點體現得更加明顯。

4. 提供Exception處理機制 .

5. 數據庫連接池管理

6. 支持I18N

缺點:
1、 轉到展現層時，須要配置forward，每一次轉到展現層，相信大多數都是直接轉到jsp，而涉及到轉向，須要配置forward，若是有十個展現層的jsp，須要配置十次struts

，並且還不包括有時候目錄、文件變動，須要從新修改forward，注意，每次修改配置以後，要求從新部署整個項目，而tomcate這樣的服務器，還必須從新啓動服務器，若是業務

變動複雜頻繁的系統，這樣的操做簡單不可想象。如今就是這樣，幾十上百我的同時在線使用咱們的系統，你們能夠想象一下，個人煩惱有多大。

2、 Struts 的Action必需是thread－safe方式，它僅僅容許一個實例去處理全部的請求。因此action用到的全部的資源都必需統一同步，這個就引發了線程安全的問題。

3、 測試不方便. Struts的每一個Action都同Web層耦合在一塊兒，這樣它的測試依賴於Web容器，單元測試也很難實現。不過有一個Junit的擴展工具Struts TestCase能夠實現它

的單元測試。

4、 類型的轉換. Struts的FormBean把全部的數據都做爲String類型，它可使用工具Commons-Beanutils進行類型轉化。但它的轉化都是在Class級別，並且轉化的類型是不

可配置的。類型轉化時的錯誤信息返回給用戶也是很是困難的。

5、 對Servlet的依賴性過強. Struts處理Action時必須要依賴ServletRequest 和ServletResponse，全部它擺脫不了Servlet容器。

6、 前端表達式語言方面.Struts集成了JSTL，因此它主要使用JSTL的表達式語言來獲取數據。但是JSTL的表達式語言在Collection和索引屬性方面處理顯得很弱。

7、 對Action執行的控制困難. Struts建立一個Action，若是想控制它的執行順序將會很是困難。甚至你要從新去寫Servlet來實現你的這個功能需求。

8、 對Action 執行前和後的處理. Struts處理Action的時候是基於class的hierarchies，很難在action處理前和後進行操做。

9、 對事件支持不夠. 在struts中，實際是一個表單Form對應一個Action類(或DispatchAction)，換一句話說：在Struts中實際是一個表單只能對應一個事件，struts這種事

件方式稱爲application event，application event和component event相比是一種粗粒度的事件。

Struts重要的表單對象ActionForm是一種對象，它表明了一種應用，這個對象中至少包含幾個字段，這些字段是Jsp頁面表單中的input字段，由於一個表單對應一個事件，所

以，當咱們須要將事件粒度細化到表單中這些字段時，也就是說，一個字段對應一個事件時，單純使用Struts就不太可能，固然經過結合JavaScript也是能夠轉彎實現的。

2．Hibernate
Hibernate是一個開放源代碼的對象關係映射框架，它對JDBC進行了很是輕量級的對象封裝，使得Java程序員能夠爲所欲爲的使用對象編程思惟來操縱數據庫。
Hibernate能夠應用在任何使用JDBC的場合，既能夠在Java的客戶端程序實用，也能夠在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate能夠在應用EJB的J2EE架構中

取代CMP，完成數據持久化的重任。
大多數開發機構常常採起建立各自獨立的數據持久層。一旦底層的數據結構發生改變，那麼修改應用的其他部分使之適應這種改變的代價將是十分巨大的。Hibernate適時的填補了

這一空白，它爲Java應用提供了一個易用的、高效率的對象關係映射框架。hibernate是個輕量級的持久性框架，功能卻很是豐富。

優勢：
a.Hibernate 使用 Java 反射機制 而不是字節碼加強程序來實現透明性。
b.Hibernate 的性能很是好，由於它是個輕量級框架。 映射的靈活性很出色。
c.它支持各類關係數據庫，從一對一到多對多的各類複雜關係。

缺點：它限制您所使用的對象模型。(例如，一個持久性類不能映射到多個表)其獨有的界面和可憐的市場份額也讓人不安，儘管如此，Hibernate 仍是以其強大的發展動力減輕了

這些風險。其餘的開源持久性框架也有一些，不過都沒有 Hibernate 這樣有市場衝擊力。

上面回貼情緒有點激動，但願諒解，我不是由於有人批評Hibernate而感到不快，而是由於帖子裏面的觀點實在讓我以爲荒謬。無論以爲Hibernate好也吧，很差也吧，我惟一以爲

遺憾的是，在中文論壇裏面找不到一個對Hibernate的真正高水平的評價。在TSS上有一個關於Hibernate的hot thread，跟了幾百貼，其中包括Hibernate做者Gavin和LiDO JDO的

CTO，對於JDO和Hibernate有過一些激烈的爭論，我曾經耐心的看了一遍，仍然沒有發現針對Hibernate真正有力的攻擊，那些所謂的攻擊無非針對Hibernate沒有一個GUI的配置工

具，沒有商業公司支持，沒有標準化等等這些站不住腳的理由。

補充幾點個人意見：

1、Hibernate是JDBC的輕量級的對象封裝，它是一個獨立的對象持久層框架，和App Server，和EJB沒有什麼必然的聯繫。Hibernate能夠用在任何JDBC可使用的場合，例如Java

應用程序的數據庫訪問代碼，DAO接口的實現類，甚至能夠是BMP裏面的訪問數據庫的代碼。從這個意義上來講，Hibernate和EB不是一個範疇的東西，也不存在非此即彼的關係。

2、Hibernate是一個和JDBC密切關聯的框架，因此Hibernate的兼容性和JDBC驅動，和數據庫都有必定的關係，可是和使用它的Java程序，和App Server沒有任何關係，也不存在

兼容性問題。

3、Hibernate不能用來直接和Entity Bean作對比，只有放在整個J2EE項目的框架中才能比較。而且即便是放在軟件總體框架中來看，Hibernate也是作爲JDBC的替代者出現的，而

不是Entity Bean的替代者出現的，讓我再列一次我已經列n次的框架結構：

傳統的架構：
1) Session Bean <-> Entity Bean <-> DB
爲了解決性能障礙的替代架構：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate來提升上面架構的開發效率的架構：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3個架構來分析：
1、內存消耗：採用JDBC的架構2無疑是最省內存的，Hibernate的架構3次之，EB的架構1最差。

2、運行效率：若是JDBC的代碼寫的很是優化，那麼JDBC架構運行效率最高，可是實際項目中，這一點幾乎作不到，這須要程序員很是精通JDBC，運用Batch語句，調整

PreapredStatement的Batch Size和Fetch Size等參數，以及在必要的狀況下采用結果集cache等等。而通常狀況下程序員是作不到這一點的。所以Hibernate架構表現出最快的運行

效率。EB的架構效率會差的很遠。

3、開發效率：在有JBuilder的支持下以及簡單的項目，EB架構開發效率最高，JDBC次之，Hibernate最差。可是在大的項目，特別是持久層關係映射很複雜的狀況下，Hibernate效

率高的驚人，JDBC次之，而EB架構極可能會失敗。

4、分佈式，安全檢查，集羣，負載均衡的支持
因爲有SB作爲Facade，3個架構沒有區別。

4、EB和Hibernate學習難度在哪裏？

EB的難度在哪裏？不在複雜的XML配置文件上，而在於EB運用稍微不慎，就有嚴重的性能障礙。因此難在你須要學習不少EJB設計模式來避開性能問題，須要學習App Server和EB的

配置來優化EB的運行效率。作EB的開發工做，程序員的大部分精力都被放到了EB的性能問題上了，反而沒有更多的精力關注自己就主要投入精力去考慮的對象持久層的設計上來。

Hibernate難在哪裏？不在Hibernate自己的複雜，實際上Hibernate很是的簡單，難在Hibernate太靈活了。

當你用EB來實現持久層的時候，你會發現EB實在是太笨拙了，笨拙到你根本沒有什麼能夠選擇的餘地，因此你根本就不用花費精力去設計方案，去平衡方案的好壞，去費腦筋考慮

選擇哪一個方案，由於只有惟一的方案擺在你面前，你只能這麼作，沒得選擇。

Hibernate相反，它太靈活了，相同的問題，你至少能夠設計出十幾種方案來解決，因此特別的犯難，究竟用這個，仍是用那個呢？這些方案之間到底有什麼區別呢？他們的運行原

理有什麼不一樣？運行效率哪一個比較好？光是主鍵生成，就有七八種方案供你選擇，你爲難不爲難？集合屬性能夠用Set，能夠用List，還能夠用Bag，到底哪一個效率高，你爲難不爲

難？查詢能夠用iterator，能夠用list，哪一個好，有什麼區別？你爲難不爲難？複合主鍵你能夠直接在hbm裏面配置，也能夠自定義CustomerType，哪一種比較好些？你爲難不爲難？

對於一個表，你能夠選擇單一映射一個對象，也能夠映射成父子對象，還能夠映射成兩個1:1的對象，在什麼狀況下用哪一種方案比較好，你爲難不爲難？

這個列表能夠一直開列下去，直到你不想再看下去爲止。當你面前擺着無數的眼花繚亂的方案的時候，你會以爲幸福呢？仍是悲哀呢？若是你是一個負責的程序員，那麼你必定會

仔細研究每種方案的區別，每種方案的效率，每種方案的適用場合，你會以爲你已經陷入進去拔不出來了。若是是用EB，你第一秒種就已經作出了決定，根本沒得選擇，好比說集

合屬性，你只能用Collection，若是是Hibernate，你會在Bag，List和Set之間來回猶豫不決，甚至搞不清楚的話，程序都沒有辦法寫。

3． Spring
它是一個開源的項目，並且目前很是活躍；它基於IoC（Inversion of Control，反向控制）和AOP的構架多層j2ee系統的框架，但它不強迫你必須在每一層 中必須使用Spring，因

爲它模塊化的很好，容許你根據本身的須要選擇使用它的某一個模塊；它實現了很優雅的MVC，對不一樣的數據訪問技術提供了統一的 接口，採用IoC使得能夠很容易的實現bean的裝

配，提供了簡潔的AOP並據此實現Transcation Managment，等等
優勢
a. Spring能有效地組織你的中間層對象，無論你是否選擇使用了EJB。若是你僅僅使用了Struts或其餘爲J2EE的 API特製的framework，Spring致力於解決剩下的問題。
b. Spring能消除在許多工程中常見的對Singleton的過多使用。根據個人經驗，這是一個很大的問題，它下降了系統的可測試性和麪向對象的程度。
c. 經過一種在不一樣應用程序和項目間一致的方法來處理配置文件，Spring能消除各類各樣自定義格式的屬性文件的須要。曾經對某個類要尋找的是哪一個魔法般的屬性項或系統屬

性感到不解，爲此不得不去讀Javadoc甚至源編碼？有了Spring，你僅僅須要看看類的JavaBean屬性。Inversion of Control的使用（在下面討論）幫助完成了這種簡化。
d. 經過把對接口編程而不是對類編程的代價幾乎減小到沒有，Spring可以促進養成好的編程習慣。
e. Spring被設計爲讓使用它建立的應用盡量少的依賴於他的APIs。在Spring應用中的大多數業務對象沒有依賴於Spring。
f. 使用Spring構建的應用程序易於單元測試。
g. Spring能使EJB的使用成爲一個實現選擇,而不是應用架構的必然選擇。你能選擇用POJOs或local EJBs來實現業務接口，卻不會影響調用代碼。
h. Spring幫助你解決許多問題而無需使用EJB。Spring能提供一種EJB的替換物，它們適用於許多web應用。例如，Spring能使用AOP提供聲明性事務管理而不經過EJB容器，若是

你僅僅須要與單個數據庫打交道，甚至不須要一個JTA實現。
i. Spring爲數據存取提供了一個一致的框架,不管是使用的是JDBC仍是O/R mapping產品（如Hibernate）。
Spring確實使你能經過最簡單可行的解決辦法來解決你的問題。而這是有有很大價值的。

缺點：使用人數很少、jsp中要寫不少代碼、控制器過於靈活，缺乏一個公用控制器

 

 

ioc就是控制反轉，能夠理解爲當spring被加載啓動後，在spring配置的bean都會被這個框架預先實例化（做用於爲單例），而後在你須要的這個對象的時候直接添加註入就能夠調用這個對象了這樣能夠大大下降了類之間的耦合度。通常對於請求的對象咱們都要用scop域，會話以上的數據和對象直接用默認的單例就好了。aop就是事務管理，用的是面向切面的技術實現的（配置都是大同小異，網上隨便找個改下就好了）。流程能夠理解爲你要給另外一我的打錢，因此業務上要分步操做，首先你要把你帳號的錢減掉，讓後再對方的帳戶添加，這是倆個步驟，對這個操做添加事務管理，就會監聽這兩個操做是否都完成，若是都完成就提交這個操做，若是有一個操做失敗了，就恢復到以前的狀態（即事