SSH與SSH2這種框架組合的歷史起因

早在2001年時當時的J2EE推崇的是EJB，EJB被稱爲J2EE的核心，當時要學J2EE就是Servlet+EJB，在EJB裏其實早已經有了AOP與實體映射這些概念了。

EJB有三種形態的BEAN，SessionBean, Entity Bean, MBEAN對吧？其中，EntityBean就是Hibernate，你們看看，嘿嘿，因此技術這個東西所謂的新也是換湯不換藥，在2001時就已經有了Hibernate這種概念了，並且Spring經典的聲明式事務代理也早就有了，就是你的SessionBean若是拋出一個java.runtime.exception，EJB容器就會自動回滾事務，並且咱們在聲明EntityBean時就是和Hibernate2.x同樣，寫一個xml文件將字段表名和類名和屬性名進行一一對應的。

可是有許多人會說ejb2.0是一個失敗之做，它的實體映射隱藏了數據庫底層的操做把對於表的操做轉化成了OOP的操做，這是一個很是好的理念，可是在早期的EJB中連對於如：selectcount(), select max()這樣的操做都沒有，固然在那時若是碰到這樣的處理時有經驗的程序員通常會採用EJB中的BPM即直接使用SessionBean+jdbc去完成的，可是就如我前面所說的，爲了使用框架而用框架的事情和人數大有所在，爲了在工程中使用一套純正的EJB，純CMP BEAN，不少程序員們就去用ArrayList.size或者是Vector.size來作這些個count,max等操做，甚至在碰到多表鏈接時對於每一個表取一個List而後在Java代碼層去用數據結構來拼裝出一個View來。

EJB2.x的配置也是很是繁瑣的，沒有一個好的現成的工具，通常不包括MBEAN的話僅要使用SessionBean和EntityBean就要配4個xml文件，同時每一個EJB的容器如：JBOSS,WEBLOGIC,WAS又彼此間不能通用，在使用不一樣的J2EE容器時還要爲這個容器單獨配一個廠商支持的xml文件。

等等等等。。。。。。這一系列致使了使用EJB的工程變得臃腫複雜，難於調試，並伴有嚴重的性能問題，當時網上罵聲也是一片，EJB一度走入低谷。因而，人們就在想，我可否保留EJB中CMPBean的這種實體映射的特性呢？並且我也只但願使用實體映射，因而Hibernate誕生了.Hibernate就是一個除去了EJB2.x一切特性只保留EntityBean的一種技術。

03年，04年隨着Hibernate的推廣，人們又在想，Hibernate如今有了，EJB原有的聲明式事務也是一個不錯的設計，我可讓程序員不須要關心他們的數據庫層面的transaction處理而只關心業務層面的transaction，因此原有EJB2.x中的AOP概念又被單獨剝離了出來，這致使了Spring的誕生.

因而在早期的人們採用Spring+Hibernate這樣的架構時，你們其實仍是在把這二者的組合在看成EJB來使用的，這樣的組合其實就是一個輕量級的EJB2.x，一個縮微了的EJB。由於EJB的設計太超前太好了，只是它的一些缺陷一些瓶勁致使程序員們錯用亂用EJB而給EJB形成了很差的口碑，可是由於J2EE的核心就是EJB，所以在04年對於Spring+Hibernate這樣的組合有一句口號叫「Thisis not a J2EE」，由於咱們不是EJB但我能作到EJB全部的優勢，呵呵。這其實就是一種無招勝有招的典形應用場景，把各自的優勢最大化的發揮出來而不拘泥於框架而來論框架.

固然，隨着EJB3的迴歸，EJB反過來吸取了Hibernate3與Spring3的一切優勢並且它藉助着SUN（如今叫ORACLESUN）的工業標準和強大的技術支持，J2EE終還將回歸EJB。

EJB3前途無量，它不只僅把SSH所有又整回成了一個EJB還簡化了配置，同時還完全作到了廠商無關，數據庫無關。如著名的SEAM3框架，SCA編程模形（EJB3的SessionBean中能夠調用Webservice，這爲EJB知足SCA編程模型中的引用、導入等概念帶來了極大的便利）都是基於EJB3的，你們有時間我以爲仍是能夠好好的去關注和學習EJB3技術。

結束今天的教程，下次開始要講在SSX體系中如何來作unit testing以及如何使用Spring來構建一個單獨運行的應用程序如：銀行保險業中的批處理業務的框架的搭建。