表現層、持久層、業務層

​為了實作web層（struts）和持久層（Hibernate）之間的松散耦合，我們采用業務代表（Business Delegate）和DAO（Data Access Object）兩種模式。DAO模式為了減少業務邏輯和資料通路邏輯之間的耦合，當一個持久曾架構被應用時，該模式将會減少業務對象和該架構之間的耦合，這樣我們可以不修改業務對象而選擇不同的持久層架構的實作。實際上在DAO模式中包含兩種結構模式：橋（Bridge）模式和擴充卡（Adaptor）模 式。 

對表現層，我們使用 Struts​；業務層使用 Spring​；對于持久層我們使用的是 Hibernate。你盡可以取代這裡的某個架構而使用你喜歡的架構已達到同樣的效果。下圖顯示了架構被整合起來時，從最高層次看到的視圖。

應用層

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

表現層

    一個典型的web 應用的末端是表現層。許多Java 開發者都知道Struts提供了什麼東西。然而，太多時候，耦合代碼比如業務邏輯被放進org.apache.struts.Action中。是以，我們 先總結一下Struts之類的架構應該提供什麼。下面就是Struts 的職責所在：

1. 管理使用者的請求和響應
2. 提供一個控制起來将調用委托到業務邏輯和其他上遊處理
3. 将來自于抛出例外的其他層的例外處理到Struts Action 中
4. 組裝可以在視圖中表現的模型對象
5. 執行UI 校驗

下面是一些經常可以使用Struts進行編碼但是不應該和表現層關聯的事情：

1. 直接和資料庫互動，比如JDBC 調用
2. 與應用相關的業務邏輯和校驗
3. 事務管理

在表現層中引入這些類型的代碼将導緻類型耦合和維護負擔。

持久層

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

1. 查詢關系資訊到對象中。Hibernate是通過稱為HQL的OO查詢語言，或者使用更有表現能力的規則 API，來完成這個工作的。除了使用對象而不是表，使用字段而不是列的方式，HQL非常類似于 SQL。也有一些新的特定的HQL 語言特征需要學習；但是，它們是很容易了解和良好編寫的。HQL是一種用于查詢對象的自然語言，而對象，隻需要很少的學習曲線吧。.
2. 存儲、更新和删除存儲在資料庫中的資訊
3. 進階的對象關系映射架構比如Hibernate支援大部分主流SQL資料庫，它們支援父/子關系，事務，繼承和多态。

下面是應該在持久層避免的一些事情：

1. 業務邏輯應該置于應用的更高層中。這裡隻允許資料通路方法。
2. 不應該使持久邏輯和表現邏輯耦合。避免表現元件如JSP或者基于servlet的類中的邏輯直接和資料訪 問進行通信。通過将持久性邏輯隔離在其自己的層中，應用将具有更加靈活的修改性而不影響到其他層的代碼。例如， Hibernate可以使用其他持久架構和API代替，而不需要修改其它層中的代碼。

1. 處理應用的業務邏輯和業務校驗
2. 管理事務
3. 允許與其他層進行互動的接口
4. 管理業務級對象之間的依賴性
5. 加入了表現和持久層之間的靈活性，以便它們不需要彼此進行直接通信
6. 從表現層暴露上下文給業務層以獲得業務服務
7. 管理從業務層到表現層的實作