Java EE開發四大常用架構,javaee四大架構
我們對Java EE的架構有過很多介紹, 本文將對Java EE中常用的四個架構做一下系統的歸納,希望大家喜歡。
Struts
Struts是一個基於Sun Java EE平台的MVC架構,主要是採用Servlet和JSP技術來實現的。
Struts架構可分為以下四個主要部分,其中三個就和MVC模式緊密相關:
1、模型 (Model),本質上來說在Struts中Model是一個Action類(這個會在後面詳細討論),開發人員通過其實現商業邏輯,同時使用者請求通過控制器(Controller)向Action的轉寄過程是基於由struts-config.xml檔案描述的配置資訊的。
2、視圖(View),View是由與控制器Servlet配合工作的一整套JSP定製標籤庫構成,利用她們我們可以快速建立應用系統的介面。
3、控制器(Controller),本質上是一個Servlet,將用戶端請求轉寄到相應的Action類。
4、一堆用來做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的一種表現,「應用程式不應依賴於容器,而是Container Service於應用程式」也是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設計模式。
願意瞭解更多的可關註:mingli.com
朋友需要詳細的瞭解更多請加球球:二零四二八四九二三七