Hibernate流行架構淺析

2009-09-21 12:50 佚名 王朝網(wǎng)絡 我要評論(0) 字號：T | T

本文向大家介紹Hibernate架構，可能好多人還不了解Hibernate架構，沒有關系，看完本文你肯定有不少收獲，希望本文能教會你更多東西。

用java來建立一個很有價值的web 應用不是一個簡單的任務。在架構這個應用時要考慮很多的因素和問題。從更高的層次來看，開發(fā)人員面臨著關于如何構建用戶接口，何處駐留業(yè)務邏輯，以及如何 實現(xiàn)數(shù)據(jù)持久性這些問題。這3層都有各自的問題需要回答。而每一層又需要實現(xiàn)那些技術?應用如何設計來進行松散耦合并能進行靈活變更?應用架構是否允許某 一層變更而不影響到其它的層次?應用應該如何處理容器一級的服務比如事務?

在為你的應用創(chuàng)建一個架構之前有許多問題需要澄清。幸運的是，有很多開發(fā)者都意識到這個問題，并建立了很多框架來解決這些問題。一個良好的框架可以 讓開發(fā)人員減輕重新建立解決復雜問題方案的負擔和精力;它可以被擴展以進行內(nèi)部的定制化;并且有強大的用戶社區(qū)來支持它。框架通常能很好的解決一個問題。 然而，你的應用是分層的，可能每一個層都需要各自的框架。僅僅解決UI問題并不意味著你能夠很好的將業(yè)務邏輯和持久性邏輯和UI 組件很好的耦合。例如，你不應該使具有JDBC代碼的業(yè)務邏輯放入控制器之中，這不是控制器應該提供的功能。一個UI 控制器應該是輕量化的組件，由它代表對UI范圍之外的其它應用層的服務調(diào)用。良好的框架自然地形成代碼分離的原則。更為重要的是，框架減輕了開發(fā)人員從頭 構建持久層代碼的精力，從而集中精力來應用邏輯上，這對客戶端來說更為重要。

本文討論了如何結合幾個著名的框架來達到松散耦合，如何設計你的架構，以及如何達到各個層次的一致性設計。面臨的挑戰(zhàn)是，將框架整合起來，以使每一 層都向另外的層次以一種松散的方式來暴露接口，而不管底層功能使用的是什么技術。本文還討論整合3種著名開源框架的一種策略。對表現(xiàn)層，我們使用 Struts;業(yè)務層使用Spring;對于持久層我們使用的是Hibernate架構。你盡可以取代這里的某個框架而使用你喜歡的框架已達到同樣的效 果。

應用層

許多設計良好的web 應用，可以被按職責分為四層。這些層次是表現(xiàn)層、持久層、業(yè)務層、和領域模型層。每一個層次都有其獨特的職責，不能把各自的功能與其它層次相混合。每一個 應用層都應該和其它層隔離開來，但允許使用接口在層間進行通信。我們開始來看看每個層，并討論一下它們各自都應該提供什么和不應該提供什么。

表現(xiàn)層

一個典型的web 應用的末端是表現(xiàn)層。許多Java 開發(fā)者都知道Struts 提供了什么東西。然而，太多時候，耦合代碼比如業(yè)務邏輯被放進org.apache.struts.Action中。所以，我們先總結一下Struts 之類的框架應該提供什么。下面就是Struts 的職責所在：
◆管理用戶的請求和響應
◆提供一個控制起來將調(diào)用委托到業(yè)務邏輯和其他上游處理
◆將來自于拋出例外的其他層的例外處理到Struts Action 中
◆組裝可以在視圖中表現(xiàn)的模型對象
◆執(zhí)行UI 校驗

下面是一些經(jīng)常可以使用Struts進行編碼但是不應該和表現(xiàn)層關聯(lián)的事情：
◆直接和數(shù)據(jù)庫交互，比如JDBC 調(diào)用
◆與應用相關的業(yè)務邏輯和校驗
◆事務管理
◆在表現(xiàn)層中引入這些類型的代碼將導致類型耦合和維護負擔。

持久層

一個典型Web應用的另一端是持久層。這也是應用中最容易很快失控的地方。開發(fā)者通常低估了自己構建自己的持久層框架的挑戰(zhàn)。一個定制的，內(nèi)部開發(fā) 的持久層不僅需要大量的開發(fā)時間，并且通常缺乏功能和難以管理。目前有許多解決這些問題的開源對象關系映射 (ORM) 框架。特別地，Hibernate架構就允許Java中的對象-關系的持久性和查詢服務。Hibernate 對已經(jīng)熟悉了SQL 和JDBC API 的Java開發(fā)者來或具有中度的學習曲線。Hibernate 的持久對象基于POJO和Java 群集(collections)。此外，使用Hibernate 不和你的IDE接口。下面列出了你需要在持久性框架中編寫的代碼類型：

存儲、更新和刪除存儲在數(shù)據(jù)庫中的信息

高級的對象關系映射框架比如Hibernate支持大部分主流SQL數(shù)據(jù)庫，它們支持父/子關系，事務，繼承和多態(tài)。

下面是應該在持久層避免的一些事情：
◆業(yè)務邏輯應該置于應用的更高層中。這里只允許數(shù)據(jù)訪問方法。
◆不應該使持久邏輯和表現(xiàn)邏輯耦 合。避免表現(xiàn)組件如JSP或者基于servlet的類中的邏輯直接和數(shù)據(jù)訪問進行通信。通過將持久性邏輯隔離在其自己的層中，應用將具有更加靈活的修改性 而不影響到其他層的代碼。例如， Hibernate 可以使用其他持久框架和API代替，而不需要修改其它層中的代碼。

業(yè)務層

典型的Web應用的中間組件一般是業(yè)務層和服務層。從編程的角度來說，service layer經(jīng)常被忽略。這種類型的代碼散布于UI表現(xiàn)層和持久層并不是不多見。這些都不是正確的地方因為它導致了緊密耦合的應用和難以維護的代碼。幸運的 是，大多數(shù)框架都解決了這個問題。這個空間內(nèi)最流行的兩個框架是Spring 和PicoContainer。它們都被視為是具有非常小的足跡(footprint)并且決定如何將你的對象整合在一起的微容器 (microcontainer)。這些框架都建立在一種叫做依賴性注入(dependency injection) (也稱控制反轉(zhuǎn)(inversion of control：IOC))的簡單概念之上。我們將關注Spring中通過針對命名配置參數(shù)的bean屬性的setter 注入的使用。Spring 也允許一種更加高級的構造器注入(constructor injection)形式作為setter injection 的可選替代。對象通過簡單的XML 文件進行連接，該配置文件包含對各種對象的引用，比如事務管理處理器(transaction management handler),對象工廠，包含業(yè)務邏輯的服務對象，以及數(shù)據(jù)訪問對象(DAO)。我們隨后會用一些例子來澄清Spring中使用這些改變的方式。業(yè)務 層應該負責下面的問題：
◆處理應用的業(yè)務邏輯和業(yè)務校驗
◆管理事務
◆允許與其他層進行交互的接口
◆管理業(yè)務級對象之間的依賴性
◆加入了表現(xiàn)和持久層之間的靈活性，以便它們不需要彼此進行直接通信
◆從表現(xiàn)層暴露上下文給業(yè)務層以獲得業(yè)務服務
◆管理從業(yè)務層到表現(xiàn)層的實現(xiàn)

領域模型層

最后，因為我們要解決實際的問題的web應用，我們需要一套在不同的層間移動的對象。領域模型層包含的是表達實際業(yè)務對象的對象，比如Order, OrderLineItem, Product 等等。這一層允許能讓開發(fā)者不再構建和維護不必要的數(shù)據(jù)傳輸對象DTO來匹配其領域?qū)ο蟆＠纾? Hibernate允許你讀取數(shù)據(jù)庫信息到一個領域?qū)ο蟮膶ο髨D中，以便你可以在離線的情況下將其表現(xiàn)在UI層中。這些對象可以被更新并跨過表現(xiàn)層發(fā)送回 去，然后進行數(shù)據(jù)庫更新。另外，你不再需要將對象轉(zhuǎn)變成DTO，因為它們在不同的層間移動時可能會丟失事務。這種模型允許Java 開發(fā)者能夠以OO風格的方式很自然的處理對象，而不用編寫額外的代碼。以上介紹Hibernate架構