Java EE開發四大經常使用框架

咱們對Java EE的框架有過不少介紹， 本文將對Java EE中經常使用的四個框架作一下系統的概括，但願你們喜歡。

Struts

Struts是一個基於Sun Java EE平臺的MVC框架，主要是採用Servlet和JSP技術來實現的。

Struts框架可分爲如下四個主要部分，其中三個就和MVC模式緊密相關：

一、模型 (Model)，本質上來講在Struts中Model是一個Action類(這個會在後面詳細討論)，開發者經過其實現商業邏輯，同時用戶請求經過控制器(Controller)向Action的轉發過程是基於由struts-config.xml文件描述的配置信息的。

二、視圖(View)，View是由與控制器Servlet配合工做的一整套JSP定製標籤庫構成，利用她們咱們能夠快速創建應用系統的界面。

三、控制器(Controller)，本質上是一個Servlet，將客戶端請求轉發到相應的Action類。

四、一堆用來作XML文件解析的工具包，Struts是用XML來描述如何自動產生一些JavaBean的屬性的，此外Struts還利用XML來描述在國際化應用中的用戶提示信息的(這樣一來就實現了應用系統的多語言支持)。

spring

Spring是輕量級的Java EE應用程序框架。

Spring的核心是個輕量級容器(Container)，實現了IoC(Inversion of Control)模式的容器，Spring的目標是實現一個全方位的整合框架，在Spring框架下實現多個子框架的組合，這些子框架之間彼此能夠獨立，也可使用其它的框架方案加以替代，Spring但願提供one-stop shop的框架整合方案 。

Spring不會特別去提出一些子框架來與現有的OpenSource框架競爭，除非它以爲所提出的框架夠新夠好，例如Spring有本身的 MVC框架方案，由於它以爲現有的MVC方案有不少能夠改進的地方，但它不強迫您使用它提供的方案，您能夠選用您所但願的框架來取代其子框架，例如您仍能夠在Spring中整合您的Struts框架 。

Spring的核心概念是IoC，IoC的抽象概念是「依賴關係的轉移」，像是「高層模組不該該依賴低層模組，而是模組都必須依賴於抽象」是 IoC的一種表現，「實現必須依賴抽象，而不是抽象依賴實現」也是IoC的一種表現，「應用程序不該依賴於容器，而是容器服務於應用程序」也是IoC的一種表現。

Spring的架構性的好處:

Spring能有效地組織你的中間層對象，不管你是否選擇使用了EJB。若是你僅僅使用了Struts或其餘的包含了Java EE特有APIs的framework，你會發現Spring關注了遺留下的問題。

Spring能消除在許多工程上對Singleton的過多使用。根據個人經驗，這是一個主要的問題，它減小了系統的可測試性和麪向對象特性。

Spring 能消除使用各類各樣格式的屬性定製文件的須要，在整個應用和工程中，可經過一種一致的方法來進行配置。曾經感到迷惑，一個特定類要查找迷幻般的屬性關鍵字或系統屬性，爲此不得不讀Javadoc乃至源編碼嗎？有了Spring，你可很簡單地看到類的JavaBean屬性。倒置控制的使用(在下面討論)幫助完成這種簡化。Spring能經過接口而不是類促進好的編程習慣，減小編程代價到幾乎爲零。

Spring被設計爲讓使用它建立的應用盡量少的依賴於他的APIs。在Spring應用中的大多數業務對象沒有依賴於Spring。

使用Spring構建的應用程序易於單元測試。

Spring能使EJB的使用成爲一個實現選擇，而不是應用架構的必然選擇。你能選擇用POJOs或local EJBs來實現業務接口，卻不會影響調用代碼。

Spring幫助你解決許多問題而無需使用EJB。Spring能提供一種EJB的替換物，它們適於許多web應用。例如，Spring能使用AOP提供聲明性事務而不經過使用EJB容器，若是你僅僅須要與單個的數據庫打交道，甚至不須要JTA實現。

Spring爲數據存取提供了一致的框架，不管是使用JDBC或O/R mapping產品(如hibernate)。

Spring確實使你能經過最簡單可行的解決辦法解決你的問題。這些特性是有很大價值的。

Spring能作什麼？

Spring提供許多功能，在此我將快速地依次展現其各個主要方面。

任務描述：

首先，讓咱們明確Spring範圍。儘管Spring覆蓋了許多方面，但咱們已經有清楚的概念，它什麼應該涉及和什麼不該該涉及。

Spring的主要目的是使Java EE易用和促進好編程習慣。

Spring 不從新開發已有的東西。所以，在Spring中你將發現沒有日誌記錄的包，沒有鏈接池，沒有分佈事務調度。這些均有開源項目提供(例如 Commons Logging 用來作全部的日誌輸出，或Commons DBCP用來做數據鏈接池)，或由你的應用程序服務器提供。由於一樣的的緣由，咱們沒有提供O/R mapping層，對此，已有有好的解決辦法如Hibernate和JDO。

Spring的目標是使已存在的技術更加易用。例如，儘管咱們沒有底層事務協調處理，但咱們提供了一個抽象層覆蓋了JTA或任何其餘的事務策略。

Spring沒有直接和其餘的開源項目競爭，除非咱們感到咱們能提供新的一些東西。例如，象許多開發人員，咱們歷來沒有爲Struts高興過，而且感到在MVC web framework中還有改進的餘地。在某些領域，例如輕量級的 IoC容器和AOP框架，Spring有直接的競爭，可是在這些領域尚未已經較爲流行的解決方案。(Spring在這些區域是開路先鋒。)

Spring也得益於內在的一致性。

全部的開發者都在唱一樣的的讚歌，基礎想法依然是Expert One-on-One Java EE設計與開發的那些。

而且咱們已經可以使用一些主要的概念，例如倒置控制，來處理多個領域。

Spring在應用服務器之間是可移植的。

固然保證可移植性老是一次挑戰，可是咱們避免任何特定平臺或非標準化，而且支持在WebLogic，Tomcat，Resin，JBoss，WebSphere和其餘的應用服務器上的用戶。

Spring的核心便是個IoC/DI的容器，它能夠幫程序設計人員完成組件之間的依賴關係注入，使得組件之間的依賴達到最小，進而提升組件的重用性，Spring是個低侵入性(invasive)的框架，Spring中的組件並不會意識到它正置身於Spring中，這使得組件能夠輕易的從框架中脫離，而幾乎不用任何的修改，反過來講，組件也能夠簡單的方式加入至框架中，使得組件甚至框架的整合變得容易。

Spring最爲人重視的另外一方面是支持AOP(Aspect-OrientedProgramming)，然而AOP框架只是Spring支持的一個子框架，說Spring框架是AOP框架並非一件適當的描述，人們對於新奇的 AOP關注映射至Spring上，使得人們對於Spring的關注集中在它的AOP框架上，雖然有所誤解，但也突顯了Spring的另外一個使人關注的特點。

Spring也提供MVC Web框架的解決方案，但您也能夠將本身所熟悉的MVC Web框架與Spring解合，像是Struts、Webwork等等，均可以與Spring整合而成爲進用於本身的解決方案。Spring也提供其它方面的整合，像是持久層的整合如JDBC、O/R Mapping工具(Hibernate、iBATIS)、事務處理等等，Spring做了對多方面整合的努力，故說Spring是個全方位的應用程序框架。

Hibernate

Hibernate是一個開放源代碼的對象關係映射框架，它對JDBC進行了輕量級的對象封裝，使得Java程序員可使用對象編程思惟來操縱數據庫。Hibernate能夠在應用EJB的JavaEE架構中取代CMP，完成數據持久化。它還能夠應用在任何使用JDBC的場合，既能夠在Java的客戶端程序實用，也能夠在Servlet/JSP的Web應用中使用

Hibernate的工做方式

Hibernate不會對您形成妨礙，也不會強迫您修改對象的行爲方式。它們不須要實現任何難以想象的接口以便可以持續存在。唯一須要作的就是建立一份XML「映射文檔」，告訴Hibernate您但願可以保存在數據庫中的類，以及它們如何關聯到該數據庫中的表和列，而後就能夠要求它以對象的形式獲取數據，或者把對象保存爲數據。與其餘解決方案相比，它幾乎已經很完美了。

因爲本文只是一篇介紹性的文章，因此不會引入構建和使用Hibernate映射文檔的具體例子(我在《Hibernate: A Developer's Notebook》一書的頭幾章中已經介紹了一個例子)。此外，在網上和Hibernate的在線文檔中，還能夠找到一些不錯的例子，請參見下面的「其餘信息」部分。它實際上至關直觀。應用程序對象中的屬性以一種簡單而天然的方式與正確的數據庫結構相關聯。

運行時，Hibernate讀取映射文檔，而後動態構建Java類，以便管理數據庫與Java之間的轉換。在 Hibernate中有一個簡單而直觀的API，用於對數據庫所表示的對象執行查詢。要修改這些對象，(通常狀況下)只需在程序中與它們進行交互，而後告訴Hibernate保存修改便可。相似地，建立新對象也很簡單;只需以常規方式建立它們，而後告訴Hibernate有關它們的信息，這樣就能在數據庫中保存它們。

Hibernate API學習起來很簡單，並且它與程序流的交互至關天然。在適當的位置調用它，就能夠達成目的。它帶來了不少自動化和代碼節省方面的好處，因此花一點時間學習它是值得的。並且還能夠得到另外一個好處，即代碼不用關心要使用的數據庫種類(不然的話甚至必須知道)。我所在的公司就曾有過在開發過程後期被迫更換數據庫廠商的經歷。這會形成巨大的災難，可是藉助於Hibernate，只須要簡單地修改Hibernate配置文件便可。

這裏的討論假定您已經經過建立Hibernate映射文檔，創建了一個關係數據庫，而且擁有要映射的Java 類。有一個Hibernate「工具集」可在編譯時使用，以支持不一樣的工做流。例如，若是您已經擁有Java類和映射文檔，Hibernate能夠爲您建立(或更新)必需的數據庫表。或者，僅僅從映射文檔開始，Hibernate也可以生成數據類。或者，它能夠反向設計您的數據庫和類，從而擬定映射文檔。還有一些用於Eclipse的alpha 插件，它們能夠在IDE中提供智能的編輯支持以及對這些工具的圖形訪問。

使用Hibernate的場合

既然Hibernate看起來如此靈活好用，爲何還要使用其餘的工具呢？下面有一些場景，能夠幫助您作出判斷(或許經過提供一些比較和上下文，能夠有助於鑑別很是適用Hibernate的場合)。

若是應用對於數據存儲的須要十分簡單——例如，您只想管理一組用戶優先選擇——您根本不須要數據庫，更不用說一個優秀的對象-關係映射系統了(即便它也如Hibernate這般易於使用)!從Java1.4開始，有一個標準的Java Preferences API能夠很好地發揮這個做用。

對於熟悉使用關係數據庫和了解如何執行完美的SQL查詢與企業數據庫交互的人來講，Hibernate彷佛有些礙手礙腳，這就像帶有動力和自動排擋的快艇車會使注重性能的賽車駕駛員不耐煩同樣。若是您屬於這種人，若是您所在的項目團隊擁有一個強大的DBA，或者有一些存儲過程要處理，您可能想研究一下iBATIS。Hibernate的建立者自己就把iBATIS看成是另外一種有趣的選擇。我對它頗有興趣，由於咱們曾爲一個電子商務站點開發了一個相似的系統(其功能更爲強大)，並且從那時到如今，咱們已經在其餘環境中使用過它，儘管在發現Hibernate以後，在新項目中咱們一般更喜歡使用Hibernate。您能夠認爲，以SQL爲中心的解決方案(好比iBATIS)是「反向的」對象/關係映射工具，而 Hibernate是一個更爲傳統的ORM。

固然，還有其餘的外部緣由會致使採用另外的方法。好比，在一個企業環境中，必須使用成熟的EJB架構(或者其餘的一些非普通對象映射系統)。能夠爲提供本身的數據存儲工具的平臺量身定作代碼，好比Mac OS X's CoreData。使用的多是像XML DTD這樣的存儲規範，而它根本不涉及關係數據庫。

可是，若是您使用的是富對象模型，並且想要靈活、輕鬆且高效地保存它(不管您是否正要開始或已經決定使用關係數據庫，只要這是一個選擇——並且存在可用的優秀免費數據庫，好比MySQL，或可嵌入Java的HSQLDB，它就應該始終是一個選擇)，那麼 Hibernate極可能就是您理想的選擇。您可能會驚訝於節省的時間之多，以及您將會多麼地喜歡使用它。

Swing

圖形用戶接口(GUI)庫最初的設計目的是讓程序員構建一個通用的GUI，使其在全部的平臺上都可以正常的顯示。可是比較遺憾的是AWT產生的是在各系統看來都一樣欠佳的圖形用戶接口，JAVA1.2爲老的java1.0 AWT添加了Java基礎類(JFC)，這是一個被稱爲「Swing」的GUI的一部分。Swing是第二代GUI開發工具集，AWT採用了與特定平臺相關的實現，而絕大部分Swing組件卻不是。Swing是構築在AWT上層的一組GUI組件的集合，爲了保證可移植性，它徹底用Java語言編寫，與AWT相比，Swing提供了更完整的組件，引入了許多新的特性和能力。Swing提供了更多的組件庫，如：JTable，JTree，Jcombox。Swing也加強了AWT中組件的功能。正是由於Swing具有了如此多的優點因此咱們之後在開發中都使用Swing。JComponent類是Swing組件的基類，而JComponent繼承自Container類，所以，全部的Swing組件都是AWT的容器。Swing採用了MVC設計模式。