摘要: 這篇文章將討論怎樣組合幾個聞名的框架去做到松耦合的目的，怎樣建立你的構架，怎樣讓你的各個應用層保持一致。富於挑戰的是：組合這些框架使得每一層都以一種松耦合的方式彼此溝通，而與底層的技術無關。這篇文章將使用３種流行的開源框架來討論組合框架的策略
其實，就算用Java建造一個不是很煩瑣的web應用程序，也不是件輕松的事情。當為一個應用程序建造一個構架時有許多事情需要考慮。從高層來說，開發者需要考慮：怎樣建立用戶接口？在哪裡處理業務邏輯？和怎樣持久化應用數據。這三層每一層都有它們各自的問題需要回答。 各個層次應該使用什麼技術？怎樣才能把應用程序設計得松耦合和能靈活改變？構架答應層的替換不會影響到其它層嗎？應用程序怎樣處理容器級的服務，比如事務處理？
當為你的web應用程序創建一個構架時，需要涉及到相當多的問題。幸運的是，已經有不少開發者已經碰到過這類重復發生的問題，並且建立了處理這類問題的框架。一個好框架具備以下幾點： 減輕開發者處理復雜的問題的負擔（“不重復發明輪子”）；內部定義為可擴展的；有一個強大的用戶群支持。框架通常能夠很好的解決一方面的問題。然而，你的應用程序有幾個層可能都需要它們各自的框架。就如解決你的用戶接口（UI）問題時你就不應該把事務邏輯和持久化邏輯摻雜進來。例如，你不應該在控制器裡面寫jdbc代碼，使它包含有業務邏輯，這不是控制器應該提供的功能。它應該是輕量級的，代理來自用戶接口（UI）外的調用請求給其它服務於這些請求的應用層。好的框架自然的形成代碼如何分布的指導。更重要的是，框架減輕開發者從頭開始寫像持久層這樣的代碼的痛苦，使他們專注於對客戶來說很重要的應用邏輯。
這篇文章將討論怎樣組合幾個聞名的框架去做到松耦合的目的，怎樣建立你的構架，怎樣讓你的各個應用層保持一致。富於挑戰的是：組合這些框架使得每一層都以一種松耦合的方式彼此溝通，而與底層的技術無關。這篇文章將使用３種流行的開源框架來討論組合框架的策略。表現層我們將使用Struts;業務層我們將使用Spring;持久層使用Hibrenate.你也可以在你的應用程序中替換這些框架中的任何一種而得到同樣的效果。圖１展示了當這些框架組合在一起時從高層看是什麼樣子。
圖1 用Struts, Spring, 和 Hibernate框架構建的概覽
應用程序的分層 大多數不復雜的web應用都能被分成至少４個各負其責的層次。這些層次是：表現層、持久層、業務層、領域模型層。每層在應用程序中都有明確的責任，不應該和其它層混淆功能。每一應用層應該彼此獨立但要給他們之間放一個通訊接口。讓我們從審閱各個層開始，討論這些層應該提供什麼和不應該提供什麼。
QQread.com
推出各大專業服務器評測 Linux服務器的安全性能
SUN服務器
HP服務器
DELL服務器
IBM服務器
聯想服務器
浪潮服務器
曙光服務器
同方服務器
華碩服務器
寶德服務器
表現層 在一個典型的web應用的一端是表現層。很多Java開發者也理解Struts所提供的。然而，太常見的是，他們把像業務邏輯之類的耦合的代碼放進了一個org.apache.struts.Action。所以，讓我們在像Struts這樣一個框架應該提供什麼上取得一致意見。這兒是Struts負責的：
·為用戶治理請求和響應；
·提供一個控制器代理調用業務邏輯和其它上層處理；
·處理從其它層擲出給一個Struts Action的異常；
·為顯示提供一個模型；
·執行用戶接口驗證。
這兒是一些經常用Struts編寫的但是卻不應該和Struts表現層相伴的項目：
·直接和數據庫通訊，比如JDBC調用；
·業務邏輯和與你的應用程序相關的驗證；
·事務治理；
·在表現層中引入這種代碼將導致典型耦合和討厭的維護。
持久層 在典型web應用的另一端是持久層。這通常是使事情迅速失控的地方。開發者低估了構建他們自己的持久層框架的挑戰性。一般來說，機構內部自己寫的持久層不僅需要大量的開發時間，而且還經常缺少功能和變得難以控制。有幾個開源的“對象－關系映射”框架非常解決問題。尤其是，Hibernate框架為java提供了＂對象－關系持久化＂機制和查詢服務。Hibernate對那些已經熟悉了SQL和JDBC API的Java開發者有一個適中的學習曲線。Hibernate持久對象是基於簡單舊式Java對象和Java集合。此外，使用Hibernate並不妨礙你正在使用的IDE。下面的列表包含了你該寫在一個持久層框架裡的代碼類型：
查詢相關的信息成為對象。Hibernate通過一種叫作HQL的面向對象的查詢語言或者使用條件表達式API來做這個事情。 HQL非常類似於SQL-- 只是把SQL裡的table和columns用Object和它的fields代替。有一些新的專用的HQL語言成分要學；不過，它們輕易理解而且文檔做得好。HQL是一種使用來查詢對象的自然語言，花很小的代價就能學習它。
保存、更新、刪除儲存在數據庫中的信息。
像Hibernate這樣的高級“對象－關系”映射框架提供對大多數主流SQL數據庫的支持，它們支持“父/子”關系、事務處理、繼續和多態。
這兒是一些應該在持久層裡被避免的項目：
業務邏輯應該在你的應用的一個高一些的層次裡。持久層裡僅僅答應數據存取操作。
你不應該把持久層邏輯和你的表現層邏輯攪在一起。避免像jsps或基於servlet的類這些表現層組件裡的邏輯和數據存取直接通訊。通過把持久層邏輯隔離進它自己的層，應用程序變得易於修改而不會影響在其它層的代碼。例如：Hebernate能夠被其它持久層框架或者API代替而不會修改在其它任何層的代碼。
業務層 在一個典型的web應用程序的中間的組件是業務層或服務層。從編碼的視角來看，這個服務層是最輕易被忽視的一層。不難在用戶接口層或者持久層裡找到散布在其中的這種類型的代碼。這不是正確的地方，因為這導致了應用程序的緊耦合，這樣一來，隨著時間推移代碼將很難維護。幸好，針對這一問題有好幾種Frameworks存在。在這個領域兩個最流行的框架是Spring和PicoContainer，它們叫作微容器，你可以不費力不費神的把你的對象連在一起。所有這些框架都工作在一個簡單的叫作“依靠注入”（也通稱“控制反轉”）的概念上。這篇文章將著眼於Spring的為指定的配置參數通過bean屬性的setter注入的使用。Spring也提供了一個構建器注入的復雜形式作為setter注入的一個替代。對象們被一個簡單的XML文件連在一起，這個XML文件含有到像事務治理器、對象工廠、包含業務邏輯的服務對象、和數據存取對象這些對象的引用。
這篇文章的後面將用例子來把Spring使用這些概念的方法說得更清楚一些。業務層應該負責下面這些事情：
·處理應用程序的業務邏輯和業務驗證；
·治理事務；
·預留和其它層交互的接口；
·治理業務層對象之間的依靠；
·增加在表現層和持久層之間的靈活性，使它們互不直接通訊；
·從表現層中提供一個上下文給業務層獲得業務服務；
·治理從業務邏輯到持久層的實現。
領域模型層 最後，因為我們討論的是一個不是很復雜的、基於web的應用程序，我們需要一組能在不同的層之間移動的對象。領域對象層由那些代表現實世界中的業務對象的對象們組成，比如：一份訂單、訂單項、產品等等。這個層讓開發者停止建立和維護不必要的數據傳輸對象（或者叫作DTOs）,來匹配他們的領域對象。例如，Hibernate答應你把數據庫信息讀進領域對象的一個對象圖，這樣你可以在連接斷開的情況下把這些數據顯示到UI層。那些對象也能被更新和送回到持久層並在數據庫裡更新。而且，你不必把對象轉化成DTOs，因為DTOs在不同的應用層間移動，可能在轉換中丟失。這個模型使得Java開發者自然地以一種面向對象的風格和對象打交道，沒有附加的編碼。
結合一個簡單的例子 既然我們已經從一個高的層次上理解了這些組件， 現在就讓我們開始實踐吧。在這個例子中，我們還是將合並Struts、Spring、Hibernate框架。每一個這些框架在一篇文章中都有太多的細節覆蓋到。這篇文章將用一個簡單的例子代碼展示怎樣把它們結合在一起，而不是進入每個框架的許多細節。示例應用程序將示范一個請求怎樣跨越每一層被服務的。這個示例應用程序的一個用戶能保存一個訂單到數據庫中和查看一個在數據庫中存在的訂單。進一步的增強可以使用戶更新或刪除一個存在的訂單。
因為領域對象將和每一層交互，我們將首先創建它們。這些對象將使我們定義什麼應該被持久化，什麼業務邏輯應該被提供，和哪種表現接口應該被設計。然後，我們將配置持久層和用Hibernate為我們的領域對象定義“對象-關系”映射。然後，我們將定義和配置我們的業務對象。在有了這些組件後，我們就能討論用Spring把這些層連在一起。最後，我們將提供一個表現層，它知道怎樣和業務服務層交流和知道怎樣處理從其它層產生的異常。
領域對象層 因為這些對象將和所有層交互，這也許是一個開始編碼的好地方。這個簡單的領域模型將包括一個代表一份訂單的對象和一個代表一個訂單項的對象。訂單對象將和一組訂單項對象有一對多的關系。例子代碼在領域層有兩個簡單的對象：
·com.meagle.bo.Order.java: 包括一份訂單的概要信息；
·com.meagle.bo.OrderLineItem.java: 包括一份訂單的具體信息；
考慮一下為你的對象選擇包名，它將反映你的應用程序是怎樣分層的。例如：簡單應用的領域對象可以放進com.meagle.bo包。更多專門的領域對象將放入在com.meagle.bo下面的子包裡。業務邏輯在com.meagle.service包裡開始打包，DAO對象放進com.meagle.service.dao.hibernate包。對於forms和actions的表現類分別放入com.meagle.action 和 com.meagle.forms包。准確的包命名為你的類提供的功能提供一個清楚的區分，使當故障維護時更易於維護，和當給應用程序增加新的類或包時提供一致性。
