java領域模型中的失血、貧血、充血、脹血模型

爲了補你們的遺憾，在此總結下ROBBIN的領域模型的一些觀點和你們的補充，在網站和演講中，robbin將領域模型初步分爲4大類：
1，失血模型
2，貧血模型
3，充血模型
4，脹血模型
那麼讓咱們看看究竟有這些領域模型的具體內容，以及他們的優缺點： 

1、失血模型 

失血模型簡單來講，就是domain object只有屬性的getter/setter方法的純數據類，全部的業務邏輯徹底由business object來完成(又稱

TransactionScript)，這種模型下的domain object被Martin Fowler稱之爲「貧血的domain object」。下面用舉一個具體的代碼來講明，代碼

來自Hibernate的caveatemptor，但通過個人改寫： 

一個實體類叫作Item，指的是一個拍賣項目 
一個DAO接口類叫作ItemDao 
一個DAO接口實現類叫作ItemDaoHibernateImpl 
一個業務邏輯類叫作ItemManager(或者叫作ItemService) 

java代碼:  

public class Item implements Serializable { 
     private Long id = null; 
     private int version; 
     private String name; 
     private User seller; 
     private String description; 
     private MonetaryAmount initialPrice; 
     private MonetaryAmount reservePrice; 
     private Date startDate; 
     private Date endDate; 
     private Set categorizedItems = new HashSet(); 
     private Collection bids = new ArrayList(); 
     private Bid successfulBid; 
     private ItemState state; 
     private User approvedBy; 
     private Date approvalDatetime; 
     private Date created = new Date(); 
     //   getter/setter方法省略不寫，避免篇幅太長 
}



java代碼:  

public interface ItemDao { 
     public Item getItemById(Long id); 
     public Collection findAll(); 
     public void updateItem(Item item); 
}



ItemDao定義持久化操做的接口，用於隔離持久化代碼。 

java代碼:  

public class ItemDaoHibernateImpl implements ItemDao extends HibernateDaoSupport { 
     public Item getItemById(Long id) { 
         return (Item) getHibernateTemplate().load(Item.class, id); 
     } 
     public Collection findAll() { 
         return (List) getHibernateTemplate().find("from Item"); 
     } 
     public void updateItem(Item item) { 
         getHibernateTemplate().update(item); 
     } 
}


ItemDaoHibernateImpl完成具體的持久化工做，請注意，數據庫資源的獲取和釋放是在ItemDaoHibernateImpl裏面處理的，每一個DAO方法調用之

前打開Session，DAO方法調用以後，關閉Session。(Session放在ThreadLocal中，保證一次調用只打開關閉一次) 

java代碼:  

public class ItemManager { 
     private ItemDao itemDao; 
     public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;} 
     public Bid loadItemById(Long id) { 
         itemDao.loadItemById(id); 
     } 
     public Collection listAllItems() { 
         return   itemDao.findAll(); 
     } 
     public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount, 
                             Bid currentMaxBid, Bid currentMinBid) throws BusinessException { 
             if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) { 
             throw new BusinessException("Bid too low."); 
     } 
    
     // Auction is active 
     if ( !state.equals(ItemState.ACTIVE) ) 
             throw new BusinessException("Auction is not active yet."); 
    
     // Auction still valid 
     if ( item.getEndDate().before( new Date() ) ) 
             throw new BusinessException("Can't place new bid, auction already ended."); 
    
     // Create new Bid 
     Bid newBid = new Bid(bidAmount, item, bidder); 
    
     // Place bid for this Item 
     item.getBids().add(newBid); 
     itemDao.update(item);      //   調用DAO完成持久化操做 
     return newBid; 
     } 
}



事務的管理是在ItemManger這一層完成的，ItemManager實現具體的業務邏輯。除了常見的和CRUD有關的簡單邏輯以外，這裏還有一個placeBid

的邏輯，即項目的競標。 

以上是一個完整的第一種模型的示例代碼。在這個示例中，placeBid，loadItemById，findAll等等業務邏輯通通放在ItemManager中實現，而

Item只有getter/setter方法。

2、貧血模型 

簡單來講，就是domain ojbect包含了不依賴於持久化的領域邏輯，而那些依賴持久化的領域邏輯被分離到Service層。 
Service(業務邏輯，事務封裝) --> DAO ---> domain object 
這也就是Martin Fowler指的rich domain object 

一個帶有業務邏輯的實體類，即domain object是Item 
一個DAO接口ItemDao 
一個DAO實現ItemDaoHibernateImpl 
一個業務邏輯對象ItemManager 

java代碼:  

public class Item implements Serializable { 
     //   全部的屬性和getter/setter方法同上，省略 
     public Bid placeBid(User bidder, MonetaryAmount bidAmount, 
                         Bid currentMaxBid, Bid currentMinBid) 
             throws BusinessException { 
    
             // Check highest bid (can also be a different Strategy (pattern)) 
             if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) { 
                     throw new BusinessException("Bid too low."); 
             } 
    
             // Auction is active 
             if ( !state.equals(ItemState.ACTIVE) ) 
                     throw new BusinessException("Auction is not active yet."); 
    
             // Auction still valid 
             if ( this.getEndDate().before( new Date() ) ) 
throw new BusinessException("Can't place new bid, auction already ended."); 
    
             // Create new Bid 
             Bid newBid = new Bid(bidAmount, this, bidder); 
    
             // Place bid for this Item 
             this.getBids.add(newBid);   // 請注意這一句，透明的進行了持久化，可是不能在這裏調用ItemDao，Item不能對ItemDao產生

依賴！ 
    
             return newBid; 
     } 
}



競標這個業務邏輯被放入到Item中來。請注意this.getBids.add(newBid); 若是沒有Hibernate或者JDO這種O/R Mapping的支持，咱們是沒法實

現這種透明的持久化行爲的。可是請注意，Item裏面不能去調用ItemDAO，對ItemDAO產生依賴！ 

ItemDao和ItemDaoHibernateImpl的代碼同上，省略。 

java代碼:  

public class ItemManager { 
     private ItemDao itemDao; 
     public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;} 
     public Bid loadItemById(Long id) { 
         itemDao.loadItemById(id); 
     } 
     public Collection listAllItems() { 
         return   itemDao.findAll(); 
     } 
     public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount, 
                             Bid currentMaxBid, Bid currentMinBid) throws BusinessException { 
         item.placeBid(bidder, bidAmount, currentMaxBid, currentMinBid); 
         itemDao.update(item);     // 必須顯式的調用DAO，保持持久化 
     } 
}



在第二種模型中，placeBid業務邏輯是放在Item中實現的，而loadItemById和findAll業務邏輯是放在ItemManager中實現的。不過值得注意的

是，即便placeBid業務邏輯放在Item中，你仍然須要在ItemManager中簡單的封裝一層，以保證對placeBid業務邏輯進行事務的管理和持久化的

觸發。 

這種模型是Martin Fowler所指的真正的domain model。在這種模型中，有三個業務邏輯方法：placeBid，loadItemById和findAll，如今的問

題是哪一個邏輯應該放在Item中，哪一個邏輯應該放在ItemManager中。在咱們這個例子中，placeBid放在Item中(可是ItemManager也須要對它進行

簡單的封裝)，loadItemById和findAll是放在ItemManager中的。 

切分的原則是什麼呢？ Rod Johnson提出原則是「case by case」，可重用度高的，和domain object狀態密切關聯的放在Item中，可重用度低

的，和domain object狀態沒有密切關聯的放在ItemManager中。 

通過上面的討論，如何區分domain logic和business logic，我想提出一個改進的區分原則： 

domain logic只應該和這一個domain object的實例狀態有關，而不該該和一批domain object的狀態有關； 

當你把一個logic放到domain object中之後，這個domain object應該仍然獨立於持久層框架以外(Hibernate,JDO)，這個domain object仍然可

以脫離持久層框架進行單元測試，這個domain object仍然是一個完備的，自包含的，不依賴於外部環境的領域對象，這種狀況下，這個logic

纔是domain logic。 
這裏有一個很肯定的原則：logic是否只和這個object的狀態有關，若是隻和這個object有關，就是domain logic；若是logic是和一批domain 

object的狀態有關，就不是domain logic，而是business logic。 


Item的placeBid這個業務邏輯方法沒有顯式的對持久化ItemDao接口產生依賴，因此要放在Item中。請注意，若是脫離了Hibernate這個持久化

框架，Item這個domain object是能夠進行單元測試的，他不依賴於Hibernate的持久化機制。它是一個獨立的，可移植的，完整的，自包含的

域對象。 

而loadItemById和findAll這兩個業務邏輯方法是必須顯式的對持久化ItemDao接口產生依賴，不然這個業務邏輯就沒法完成。若是你要把這兩

個方法放在Item中，那麼Item就沒法脫離Hibernate框架，沒法在Hibernate框架以外獨立存在。

這種模型的優勢： 
一、各層單向依賴，結構清楚，易於實現和維護 
二、設計簡單易行，底層模型很是穩定 
這種模型的缺點： 
一、domain object的部分比較緊密依賴的持久化domain logic被分離到Service層，顯得不夠OO 
二、Service層過於厚重 

3、充血模型 
充血模型和第二種模型差很少，所不一樣的就是如何劃分業務邏輯，即認爲，絕大多業務邏輯都應該被放在domain object裏面(包括持久化邏輯)

，而Service層應該是很薄的一層，僅僅封裝事務和少許邏輯，不和DAO層打交道。 
Service(事務封裝) ---> domain object <---> DAO 
這種模型就是把第二種模型的domain object和business object合二爲一了。因此ItemManager就不須要了，在這種模型下面，只有三個類，他

們分別是： 

Item：包含了實體類信息，也包含了全部的業務邏輯 
ItemDao：持久化DAO接口類 
ItemDaoHibernateImpl：DAO接口的實現類 

因爲ItemDao和ItemDaoHibernateImpl和上面徹底相同，就省略了。 

java代碼:  

public class Item implements Serializable { 
     //   全部的屬性和getter/setter方法都省略 
    private static ItemDao itemDao; 
     public void setItemDao(ItemDao itemDao) {this.itemDao = itemDao;} 
    
     public static Item loadItemById(Long id) { 
         return (Item) itemDao.loadItemById(id); 
     } 
     public static Collection findAll() { 
         return (List) itemDao.findAll(); 
     } 

     public Bid placeBid(User bidder, MonetaryAmount bidAmount, 
                     Bid currentMaxBid, Bid currentMinBid) 
     throws BusinessException { 
    
         // Check highest bid (can also be a different Strategy (pattern)) 
         if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) { 
                 throw new BusinessException("Bid too low."); 
         } 
        
         // Auction is active 
         if ( !state.equals(ItemState.ACTIVE) ) 
                 throw new BusinessException("Auction is not active yet."); 
        
         // Auction still valid 
         if ( this.getEndDate().before( new Date() ) ) 
                 throw new BusinessException("Can't place new bid, auction already ended."); 
        
         // Create new Bid 
         Bid newBid = new Bid(bidAmount, this, bidder); 
        
         // Place bid for this Item 
         this.addBid(newBid); 
         itemDao.update(this);       //   調用DAO進行顯式持久化 
         return newBid; 
     } 
}



在這種模型中，全部的業務邏輯所有都在Item中，事務管理也在Item中實現。
這種模型的優勢： 
一、更加符合OO的原則 
二、Service層很薄，只充當Facade的角色，不和DAO打交道。 
這種模型的缺點： 
一、DAO和domain object造成了雙向依賴，複雜的雙向依賴會致使不少潛在的問題。 
二、如何劃分Service層邏輯和domain層邏輯是很是含混的，在實際項目中，因爲設計和開發人員的水平差別，可能致使整個結構的混亂無序。 
三、考慮到Service層的事務封裝特性，Service層必須對全部的domain object的邏輯提供相應的事務封裝方法，其結果就是Service徹底重定義

一遍全部的domain logic，很是煩瑣，並且Service的事務化封裝其意義就等於把OO的domain logic轉換爲過程的Service TransactionScript

。該充血模型辛辛苦苦在domain層實現的OO在Service層又變成了過程式，對於Web層程序員的角度來看，和貧血模型沒有什麼區別了。 

1.事務我是不但願由Item管理的，而是由容器或更高一層的業務類來管理。 

2.若是Item不脫離持久層的管理，如JDO的pm，那麼itemDao.update(this); 是不須要的，也就是說Item是在事務過程當中從數據庫拿出來的，並

且聲明週期不超出當前事務的範圍。 

3.若是Item是脫離持久層，也就是在Item的生命週期超出了事務的範圍，那就要必須顯示調用update或attach之類的持久化方法的，這種時候

就應該是按robbin所說的第2種模型來作。

4、脹血模型 
基於充血模型的第三個缺點，有同窗提出，乾脆取消Service層，只剩下domain object和DAO兩層，在domain object的domain logic上面封裝

事務。 
domain object(事務封裝，業務邏輯) <---> DAO 
彷佛ruby on rails就是這種模型，他甚至把domain object和DAO都合併了。 
該模型優勢： 
一、簡化了分層 
二、也算符合OO 
該模型缺點： 
一、不少不是domain logic的service邏輯也被強行放入domain object ，引發了domain ojbect模型的不穩定 
二、domain object暴露給web層過多的信息，可能引發意想不到的反作用。





評價：



在這四種模型當中，失血模型和脹血模型應該是不被提倡的。而貧血模型和充血模型從技術上來講，都已是可行的了。可是我我的仍然主張

使用貧血模型。其理由： 

一、參考充血模型第三個缺點，因爲暴露給web層程序拿到的仍是Service Transaction Script，對於web層程序員來講，底層OO意義喪失了。 

二、參考充血模型第三個缺點，爲了事務封裝，Service層要給每一個domain logic提供一個過程化封裝，這對於編程來講，作了多餘的工做，非

常煩瑣。 

三、domain object和DAO的雙向依賴在作大項目中，考慮到團隊成員的水平差別，很容易引入不可預知的潛在bug。 

四、如何劃分domain logic和service logic的標準是不肯定的，每每要根據我的經驗，有些人就是以爲某個業務他更加貼近domain，也有人認

爲這個業務是貼近service的。因爲劃分標準的不肯定性，帶來的後果就是實際項目中會產生不少這樣的爭議和糾紛，不一樣的人會有不一樣的劃分

方法，最後就會形成整個項目的邏輯分層混亂。這不像貧血模型中我提出的按照是否依賴持久化進行劃分，這種標準是很是肯定的，不會引發

爭議，所以團隊開發中，不會產生此類問題。 

五、貧血模型的domain object確實不夠rich，可是咱們是作項目，不是作研究，好用就好了，管它是否是那麼純的OO呢？其實我不一樣意

firebody認爲的貧血模型在設計模型和實現代碼中有很大跨越的說法。一個設計模型到實現的時候，你直接獲得兩個類：一個實體類，一個控

制類就好了，沒有什麼跨越。 

簡單評價一下： 

第一種模型絕大多數人都反對，所以反對理由我也很少講了。但遺憾的是，我觀察到的實際情形是，不少使用Hibernate的公司最後都是這種模

型，這裏面有很大的緣由是不少公司的技術水平沒有達到這種層次，因此致使了這種貧血模型的出現。從這一點來講，Martin Fowler的批評聲

音不是太響了，而是太弱了，還須要再繼續吶喊。 

第二種模型就是Martin Fowler一直主張的模型，實際上也是我一直在實際項目中採用這種模型。我沒有看過Martin的POEAA，之因此可以本身

摸索到這種模型，也是由於從02年我已經開始思考這個問題而且尋求解決方案了，可是當時沒有看到Hibernate，那時候作的一個小型項目我已

經按照這種模型來作了，可是因爲沒有O/R Mapping的支持，寫到後來又不得不所有改爲貧血的domain object，項目作完之後再繼續找，隨後

就發現了Hibernate。固然，如今不少人一開始就是用Hibernate作項目，沒有經歷過我經歷的那個階段。 

不過我以爲這種模型仍然不夠完美，由於你仍是須要一個業務邏輯層來封裝全部的domain logic，這顯得很是羅嗦，而且業務邏輯對象的接口

也不夠穩定。若是不考慮業務邏輯對象的重用性的話(業務邏輯對象的可重用性也不可能好)，不少人乾脆就去掉了xxxManager這一層，在Web層

的Action代碼直接調用xxxDao，同時容器事務管理配置到Action這一層上來。Hibernate的caveatemptor就是這樣架構的一個典型應用。 

第三種模型是我很反對的一種模型，這種模型下面，Domain Object和DAO造成了雙向依賴關係，沒法脫離框架測試，而且業務邏輯層的服務也

和持久層對象的狀態耦合到了一塊兒，會形成程序的高度的複雜性，不好的靈活性和糟糕的可維護性。也許未來技術進步致使的O/R Mapping管理

下的domain object發展到足夠的動態持久透明化的話，這種模型纔會成爲一個理想的選擇。就像O/R Mapping的流行使得第二種模型成爲了可

能

Martin Fowler的Domain Model，或者說咱們的第二種模型難道是天衣無縫的嗎？固然不是，接下來我就要分析一下它的不足，以及可能的解決

辦法，而這些都來源於我我的的實踐探索。 

在第二種模型中，咱們能夠清楚的把這4個類分爲三層： 

一、實體類層，即Item，帶有domain logic的domain object 
二、DAO層，即ItemDao和ItemDaoHibernateImpl，抽象持久化操做的接口和實現類 
三、業務邏輯層，即ItemManager，接受容器事務控制，向Web層提供統一的服務調用 

在這三層中咱們你們能夠看到，domain object和DAO都是很是穩定的層，其實緣由也很簡單，由於domain object是映射數據庫字段的，數據庫

字段不會頻繁變更，因此domain object也相對穩定，而面向數據庫持久化編程的DAO層也不過就是CRUD而已，不會有更多的花樣，因此也很穩

定。 

問題就在於這個充當business workflow facade的業務邏輯對象，它的變更是至關頻繁的。業務邏輯對象一般都是無狀態的、受事務控制的、

Singleton類，咱們能夠考察一下業務邏輯對象都有哪幾類業務邏輯方法： 

第一類：DAO接口方法的代理，就是上面例子中的loadItemById方法和findAll方法。 

ItemManager之因此要代理這種類，目的有兩個：向Web層提供統一的服務調用入口點和給持久化方法增長事務控制功能。這兩點都很容易理解

，你不能既給Web層程序員提供xxxManager，也給他提供xxxDao，因此你須要用xxxManager封裝xxxDao，在這裏，充當了一個簡單代理功能；而

事務控制也是持久化方法必須的，事務可能須要跨越多個DAO方法調用，因此必須放在業務邏輯層，而不能放在DAO層。 

可是必須看到，對於一個典型的web應用來講，絕大多數的業務邏輯都是簡單的CRUD邏輯，因此這種狀況下，針對每一個DAO方法，xxxManager都

須要提供一個對應的封裝方法，這不可是很是枯燥的，也是使人感受很是很差的。 


第二類：domain logic的方法代理。就是上面例子中placeBid方法。雖然Item已經有了placeBid方法，可是ItemManager仍然須要封裝一下Item

的placeBid，而後再提供一個簡單封裝以後的代理方法。 

這和第一種狀況相似，其緣由也同樣，也是爲了給Web層提供一個統一的服務調用入口點和給隱式的持久化動做提供事務控制。 

一樣，和第一種狀況同樣，針對每一個domain logic方法，xxxManager都須要提供一個對應的封裝方法，一樣是枯燥的，使人不爽的。 


第三類：須要多個domain object和DAO參與協做的business workflow。這種狀況是業務邏輯對象真正應該完成的職責。 

在這個簡單的例子中，沒有涉及到這種狀況，不過你們均可以想像的出來這種應用場景，所以沒必要舉例說明了。 

經過上面的分析能夠看出，只有第三類業務邏輯方法纔是業務邏輯對象真正應該承擔的職責，而前兩類業務邏輯方法都是「無奈之舉」，不得

不爲之的事情，不但枯燥，並且使人沮喪。 




分析完了業務邏輯對象，咱們再回頭看一下domain object，咱們要仔細考察一下domain logic的話，會發現domain logic也分爲兩類： 

第一類：須要持久層框架隱式的實現透明持久化的domain logic，例如Item的placeBid方法中的這一句： 
java代碼:  

this.getBids().add(newBid);


上面已經着重提到，雖然這僅僅只是一個Java集合的添加新元素的操做，可是實際上經過事務的控制，會潛在的觸發兩條SQL：一條是insert一

條記錄到bid表，一條是更新item表相應的記錄。若是咱們讓Item脫離Hibernate進行單元測試，它就是一個單純的Java集合操做，若是咱們把

他加入到Hibernate框架中，他就會潛在的觸發兩條SQL，這就是隱式的依賴於持久化的domain logic。 
特別請注意的一點是：在沒有Hibernate/JDO這類能夠實現「透明的持久化」工具出現以前，這類domain logic是沒法實現的。 

對於這一類domain logic，業務邏輯對象必須提供相應的封裝方法，以實現事務控制。 


第二類：徹底不依賴持久化的domain logic，例如readonly例子中的Topic，以下： 

java代碼:  

class Topic { 
     boolean isAllowReply() { 
         Calendar dueDate = Calendar.getInstance(); 
         dueDate.setTime(lastUpdatedTime); 
         dueDate.add(Calendar.DATE, forum.timeToLive); 
    
         Date now = new Date(); 
         return now.after(dueDate.getTime()); 
     } 
}



注意這個isAllowReply方法，他和持久化徹底不發生一丁點關係。在實際的開發中，咱們一樣會遇到不少這種不須要持久化的業務邏輯(主要發

生在日期運算、數值運算和枚舉運算方面)，這種domain logic無論脫離不脫離所在的框架，它的行爲都是一致的。對於這種domain logic，業

務邏輯層並不須要提供封裝方法，它能夠適用於任何場合。
歸納說：action作爲控制器 ，service面向use case，domain object是中間穩定的一層，dao是做爲下層的服務，提供持久化服務，能夠被

domain object所使用。 
針對上面帖子中分析的業務邏輯對象的方法有三類的狀況，咱們在實際的項目中會遇到一些困擾。主要的困擾就是業務邏輯對象的方法會變更

的至關頻繁，而且業務邏輯對象的方法數量會很是龐大。針對這個問題，我所知道的有兩種解決方案，我姑且稱之爲第二種模型的兩類變種： 

第一類變種就是partech的那種模型，簡單的來講，就是把業務邏輯對象層和DAO層合二爲一；第二類變種就是乾脆取消業務邏輯層，把事務控

制前推至Web層的Action層來處理，下面分別分析一下兩類變種的優缺點:

第一類變種是合併業務邏輯對象和DAO層，這種設計代碼簡化爲3個類，以下所示： 

一個domain object：Item(同第二種模型的代碼，省略) 
一個業務層接口：ItemManager(合併原來的ItemManager方法簽名和ItemDao接口而來) 
一個業務層實現類：ItemManagerHibernateImpl(合併原來的ItemManager方法實現和ItemDaoHibernateImpl) 

java代碼:  

public interface ItemManager { 
     public Item loadItemById(Long id); 
     public Collection findAll(); 
     public void updateItem(Item item); 
     public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount, Bid currentMaxBid, Bid currentMinBid) throws 

BusinessException; 
}



java代碼:  

public class ItemManagerHibernateImpl implements ItemManager extends HibernateDaoSupport { 
     public Item loadItemById(Long id) { 
         return (Item) getHibernateTemplate().load(Item.class, id); 
     } 
     public   Collection findAll() { 
         return (List) getHibernateTemplate().find("from Item"); 
     } 
     public void updateItem(Item item) { 
         getHibernateTemplate().update(item); 
     } 
     public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount, Bid currentMaxBid, Bid currentMinBid) throws 

BusinessException { 
         item.placeBid(bidder, bidAmount, currentMaxBid, currentMinBid); 
         updateItem(item);    //   確保持久化item 
     } 
}



第二種模型的第一類變種把業務邏輯對象和DAO層合併到了一塊兒。 
考慮到典型的web應用中，簡單的CRUD操做佔據了業務邏輯的絕大多數比例，所以第一類變種的優勢是：避免了業務邏輯不得不大量封裝DAO接

口的問題，簡化了軟件架構設計，節省了大量的業務層代碼量。 
這種方案的缺點是：把DAO接口方法和業務邏輯方法混合到了一塊兒，顯得職責不夠單一化，軟件分層結構不夠清晰；此外這種方案仍然不得不對

隱式依賴持久化的domain logic提供封裝方法，未能作到完全的簡化。 

整體而言，我的認爲這種變種各方面權衡下來，是目前相對最爲合理方案，這也是我目前項目中採用的架構
第二種模型的第二類變種就是乾脆取消ItemManager，保留原來的Item，ItemDao，ItemDaoHibernateImpl這3個類。在這種狀況下把事務控制前

推至Web層的Action去控制，具體來講，就是直接對Action的execute()方法進行容器事務聲明。 

這種方式的優勢是：極大的簡化了業務邏輯層，避免了業務邏輯對象不得不大量封裝DAO接口方法和大量封裝domain logic的問題。對於業務邏

輯很是簡單的項目，採用這種方案是一個很是合適的選擇。 

這種方式的缺點主要有3個： 

1) 因爲完全取消了業務邏輯對象層，對於那些有重用須要的、多個domain object和多個DAO參與的、複雜業務邏輯流程來講，你不得不在

Action中一遍又一遍的重複實現這部分代碼，效率既低，也不利於軟件重用。 

2) Web層程序員須要對持久層機制有至關高程度的瞭解和掌握，必須知道何時應該調用什麼DAO方法進行必要的持久化。 

3) 事務的範圍被擴大了。假設你在一個Action中，首先須要插入一條記錄，而後再須要查詢數據庫，顯示一個記錄列表，對於這種狀況，事務

的做用範圍應該是在插入記錄的先後，可是如今擴大到了整個execute執行期間。若是插入動做完畢，查詢動做過程當中出現通往數據庫服務器的

網絡異常，那麼前面的插入動做將回滾，可是實際上咱們指望的是插入應該被提交。 

整體而言，這種變種的缺陷比較大，只適合在業務邏輯很是簡單的小型項目中，值得一提的是Hibernate的caveatemptor就是採用這種變種的架

構，你們能夠參考一下。 

綜上所述，在採用Rich Domain Object模型的三種解決方案中(第二模型，第二模型第一變種，第二模型第二變種)，我認爲權衡下來，第二模

型的第一變種是相對最好的解決方案，不過它仍然有必定的不足，在這裏我也但願你們可以提出更好的解決方案。
，partech 提出了 實體控制對象 和 實體對象 兩種不一樣層次的 Domain Object ，因爲 Domain Object 能夠依賴於 XXXFinderDAO，所以，也

就不存在「大數據量問題」，所以，整個 Domain 體系，對於實際業務表述的更爲完整，更爲一體化。我很是傾向這種方式。
通常是這樣的順序： 
Client-->Service-->D Object-->DAO-->DB 
至於哪些該放在哪裏，基本有這樣的原則：（就是robbin的第二種了） 
DO封裝內在的業務邏輯 
Service 封裝外在於DO的業務邏輯 

固然若是業務邏輯簡單或者沒有的話也能夠： 
Client-->D Object-->DAO-->DB 

對於第二種的第一個變種當然是個好辦法，但如Robbin所說也有缺陷若是有多個Servcie要調用DAO的話，就有問題了。合併也意味中不能很好

的重用 

說到底就是粒度的問題，分得細重用好，但類多、結構複雜、繁瑣。分得粗（乾脆用一個類幹全部的事）重用差，但類少、結構簡單