許多設計良好的web應用，可以被按職責分為四層。這些層次是表現層、持久層、業務層、和域模型層。每一個層次都有其獨特的職責，不能把各自的功能與其它層次相混合。每一個應用層都應該和其它層隔離開來，但允許使用介面在層間進行通訊。我們開始來看看每個層，並討論一下它們各自都應該提供什麼和不應該提供什麼。 
 
對錶現層，我們使用 Struts ；業務層使用 Spring ；對於持久層我們使用的是 Hibernate 。你儘可以取代這裡的某個框架而使用你喜歡的框架已達到同樣的效果。上圖顯示了框架被整合起來時，從最高層次看到的檢視。 
ref：http://www.blogjava.net/jiabao/archive/2007/04/08/109189.html

1. 持久層（Persistence layer–DAO–hibernate）

所謂持久，就是把資料儲存到可以永久保持的儲存裝置當中。一般來說，持久更為直接的理解就是對資料庫的各種操作，如增加，刪除，修改，查詢，更新等操作。 
持久層，就是把持久的動作封裝成一個獨立的層，這是為了降低功能程式碼之間的關聯。建立一個更清晰的抽象，提高程式碼的內聚力，降低程式碼的耦合度，從而增強程式碼的要勞動局生和可重用性。 
持久層可以封裝資料訪問細節，為大部分業務邏輯提供面向物件的API。它是一種鬆散耦合，使持久化不依賴於義憤資料庫和上層業務邏輯來實現。我們在設計程式碼的時候，應該避免在業務邏輯程式碼中混雜資料訪問程式碼。 
DAO，即持久層資料訪問物件。利用來抽象和封裝所有對資料來源的訪問，由DAO來管理各種資料來源的連線以便於檢索和儲存資料。DAO一般由業務物件，資料訪問物件，資料來源和值物件組成。通過DAO實現了資料訪問邏輯的抽象與實現細節的封裝，只對外提供一個抽象化的資料訪問API。我們通過呼叫API的方法就能實現對資料庫的操作。而不必再去理解具體是怎麼對資料庫進行操作的。這樣由於業務操作和資料訪問實現分離，也使得開發人員的專業劃分成為可能。 
在DAO中業務物件僅僅包含與本領域相關的邏輯物件和演算法就可以了。針對不同的資料庫提供各自的資料訪問程式碼，可以通過定義一個呼叫介面，針對該介面實現不同資料的資料訪問。這樣就可以避免對具體實現的依賴，在以後資料庫變更時，不用改實現的程式碼。 
Dao層是可以使用Hibernate連線資料庫、操作資料庫（簡單的增刪改查）。其和DAO設計模式還不完全是一個概念，我們此處的Dao層中不包含實體類的描述，這部分寫在域模型層： 
DAO設計模式一般分為幾個類： 
1.VO(Value Object)：一個用於存放網頁的一行資料即一條記錄的類，比如網頁要顯示一個使用者的資訊，則這個類就是使用者的類。 
2.DatabaseConnection：用於開啟和關閉資料庫。 
3.DAO介面：用於宣告對於資料庫的操作。 
4.DAOImpl：必須實現DAO介面，真實實現DAO介面的函式，但是不包括資料庫的開啟和關閉。 
5.DAOProxy：也是實現DAO介面，但是隻需要藉助DAOImpl即可，但是包括資料庫的開啟和關閉。 
6.DAOFactory：工廠類，含有getInstance()建立一個Proxy類。 
ref：

2. 表現層（UI Layer –Presentation Layer–struts-action層 ）

action層負責選擇不同的展示UI，為了保證系統能夠在不同的UI介面做移植，action不要涉及業務邏輯。 
一個典型的web 應用的末端是表現層。許多Java 開發者都知道Struts提供了什麼東西。然而，太多時候，耦合程式碼比如業務邏輯被放進org.apache.struts.Action中。所以，我們先總結一下Struts之類的框架應該提供什麼。下面就是Struts 的職責所在： 
1.管理使用者的請求和響應 
2.提供一個控制起來將呼叫委託到業務邏輯和其他上游處理 
3.將來自於丟擲例外的其他層的例外處理到Struts Action 中 
4.組裝可以在檢視中表現的模型物件 
5.執行UI 校驗 
下面是一些經常可以使用Struts進行編碼但是不應該和表現層關聯

3. 業務層（Bussiness Layer –service-spring-beanFactory）

Service層：引用對應的Dao資料庫操作，在這裡可以編寫自己需要的程式碼（比如簡單的判斷）。 
service層是呼叫各種dao的業務操作，比如你有一個業務是 新增，然後修改。 那麼你分別呼叫dao的新增和修改操作，包括裡面的一些資料轉換，邏輯判斷都放到service層，dao只是單純的增刪改查。 而且事務一般會放到service層。 
其中Service層和DAO層由於可能都會對資料庫進行操作，其具體區別為：

1. dao和service對應

   一般情況下,Hibernate DAO只操作一個POJO物件，因此一個DAO對應一個POJO物件。 Service層是為了處理包含多個POJO物件（即對多個表的資料操作）時，進行事務管理（宣告式事務管理）。Service層（其介面的實現類）被注入多個DAO物件，以完成其資料操作。

2. Service之有無 
   這一點我的看法未必正確,我的腦海現在有兩種構建業務層的模式: 
   模式1是Service + DAO,即DAO中只做CRUD及類似的簡單操作(稱之為功能點,不包含業務邏輯),Service中通過呼叫一個或多個DAO中的功能點來組合成為業務邏輯.Service的數量應該由功能模組來決定。 
   在這種模型中業務邏輯是放在Service中的,事務的邊界也應該在Service中控制. 當然,直接在Service中控制事務會引入非業務邏輯的程式碼,幸好Spring的AOP可以解決這個問題,這也是引入Spring的原因之一. 
   如果說到缺點,就在於對某些物件的操作就是簡單的CRUD,Service層顯得累贅. 模式2是Service + BO, 而BO = DAO + 業務方法, 在原先DAO的基礎上新增業務方法,形成BO物件。需要注意的是BO中的業務方法往往是針對一個實體物件的，如果需要跨越多個實體物件，則方法應該放在Service中。 
   舉例來說，一個簡單的銀行帳戶管理系統，建立帳戶這個BO物件，裡面可以有修改密碼，取錢等業務方法（不難看出，這些方法都只對單個帳戶物件進行操作）。現在需要新增一個轉賬方法，就應該放在Service中。 
   這裡Service和BO的關係是什麼樣的呢？再舉一例：以國家行政機關為例：糧食局負責收糧，賣種子等，建設部負責審批土地買賣，建設公路等，這都是行政部分份內的事兒。突然某地發了水災，救災時需要糧食局開倉放糧，建設部修建臨時房屋，如何協調兩個部門？就需要成立專門的救災委員會，由救災委員會出面對兩個部分的資源進行調撥。這裡兩個部分就是BO，而救災委員會就是Service。不知我的意思是否表達準確了，呵呵。 模式1的在劃分Service和DAO時界限清晰，但會帶來一些無必要的程式碼。 
   模式2的劃分相對複雜，然而可以提高編碼效率。 
   當然小規模的應用中，沒有Service，完全是DAO或BO也是可以接受的。

3. Service和DAO的介面之有無

介面是一種契約，它可以有多種實現。所以介面之有無取決於具體實現是否需要多樣化。如果鐵定一種DAO或一種Service只有一種實現，那麼抽象出介面的意義不大。然而一些大型應用或許需要DAO和Service的多種實現（比如上面例子中的帳戶DAO，可能需要一種Hibernate實現、一種CMP實現和一種JDO實現），為了向上一層隱藏具體實現類，需要採用介面。

隱藏具體實現類的建立過程，這有兩種方法：一是實用工廠方法，代價是程式碼量大（每個DAO和Service一個工廠）。二是使用Spring的IoC，實現依賴注入，不需要寫額外的程式碼，這也是引入Spring的理由之二。 
ref：http://blog.csdn.net/njujmj/article/details/5202915

4. 域模型層（Domain model）

軟體開發要幹什麼： 
反映真實世界要自動化的業務流程 
解決現實問題 
領域Domain 
Domain特指軟體關注的領域 
在不能充分了解業務領域的情況下是不可能做出一個好的軟體 
Domain層是整個系統的核心層，該層維護一個使用面向物件技術實現的領域模型，幾乎全部的業務邏輯會在該層實現。 
Domain層包含: 
1.Entity（實體）： 
有一類物件擁有唯一識別符號能夠跨越系統的生命週期甚至能超越軟體系統的一系列的延續性和識別符號這樣的物件稱為實體。 
2.ValueObject(值物件) 
對某個物件是什麼不感興趣，只關心它擁有的屬性用來描述領域的特殊方面、且沒有識別符號的一個物件，叫做值物件,能被簡單的建立和丟棄，生命週期中不會被持久化值物件可以被共享，值物件應該不可變 
3.Domain Event（領域事件） 
4.Repository（倉儲）等 
ref：http://blog.csdn.net/johnstrive/article/details/16805121

轉載自：http://blog.csdn.net/zcf396720/article/details/51372580