上周翻譯了MartinFowler的貧血模型，當(dāng)即就答應(yīng)溫老師了溫謙老師提出能不能寫個(gè)示例來解釋一下貧血模型的要求。在網(wǎng)上也查了一些資料，本想轉(zhuǎn)載一篇，轉(zhuǎn)念一想，算了吧，按自己的理解去寫吧。不論對與錯(cuò)，為大家提供一個(gè)靶子，同意也好，反對也罷，希望大家也把自己的見解記錄在這里。
在這里再次聲明下，本人功力尚淺，難免有理解不到位的地方，所以還請大家在閱讀的時(shí)候發(fā)現(xiàn)并指正。
打算借助事物腳本和領(lǐng)域模型兩種方式來揭開貧血與充血之間的異同。
我們先了解一下事物腳本和領(lǐng)域模型的概念。
事物腳本：
事務(wù)腳本的核心是過程，通過過程的調(diào)用來組織業(yè)務(wù)邏輯，每個(gè)過程處理來自表現(xiàn)層的單個(gè)請求。大部分業(yè)務(wù)應(yīng)用都可以被看成一系列事務(wù)，從某種程度上來說，通過事務(wù)腳本處理業(yè)務(wù)，就像執(zhí)行一條條Sql語句來實(shí)現(xiàn)數(shù)據(jù)庫信息的處理。事務(wù)腳本把業(yè)務(wù)邏輯組織成單個(gè)過程，在過程中直接調(diào)用數(shù)據(jù)庫，業(yè)務(wù)邏輯在服務(wù)（Service）層處理。
領(lǐng)域模型：
領(lǐng)域模型的特點(diǎn)也比較明顯， 屬于面向?qū)ο笤O(shè)計(jì)，領(lǐng)域模型具備自己的屬性行為狀態(tài)，并與現(xiàn)實(shí)世界的業(yè)務(wù)對象相映射。各類具備明確的職責(zé)劃分，領(lǐng)域?qū)ο笤刂g通過聚合和引用等關(guān)系配合解決實(shí)際業(yè)務(wù)應(yīng)用和規(guī)則。可復(fù)用，可維護(hù)，易擴(kuò)展，可以采用合適的設(shè)計(jì)模型進(jìn)行詳細(xì)設(shè)計(jì)。缺點(diǎn)是相對復(fù)雜，要求設(shè)計(jì)人員有良好的抽象能力。
大家很奇怪吧，標(biāo)題不是“貧血模型與充血模型的對比”嗎，怎么扯到事物腳本和領(lǐng)域模型上了呢。我是這樣理解的：在面向事物腳本編程中所使用的對象就是我們今天的主角之一“貧血模型”，當(dāng)然領(lǐng)域模型自然也就對應(yīng)著“充血模型”。那么他們最大的區(qū)別在哪里呢？其實(shí)Marth Folwer的貧血模型一文中已明確說明貧血模型是一種反模式，它根本就不是面向?qū)ο蟮漠a(chǎn)物，違反面向?qū)ο蟮暮诵乃枷?，而充血模型則契合面向?qū)ο蟮乃枷?。換句話說，貧血模型中只有屬性，不存在領(lǐng)域操作，僅僅是被當(dāng)做一種數(shù)據(jù)結(jié)構(gòu)來使用。而充血模型有血有肉，既有屬性，又有領(lǐng)域操作，貫徹面向?qū)ο蟮乃枷?。啰嗦?.....
又想起來一點(diǎn)，在閱讀池建強(qiáng)老師在infoq上的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)和實(shí)踐與《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)-軟件核心復(fù)雜性應(yīng)對之道》一書過程中才恍然大悟到：運(yùn)用面向?qū)ο笳Z言不一定編寫出來的就是面向?qū)ο蟮某绦?。然覺悟到，原來從開始到現(xiàn)在所編寫的程序統(tǒng)統(tǒng)與面向?qū)ο笥谐鋈?，乃純粹的面向事物腳本或者說面向過程化編程。
言歸正傳，首先我們從使用貧血模型與使用充血模型編程時(shí)，各自分包的特點(diǎn)。
貧血模型的包結(jié)構(gòu)，如下圖：
這個(gè)結(jié)構(gòu)是我在實(shí)際開發(fā)中使用的，大家看著是否有熟悉的感覺！解釋起來也很輕松，entity自然就是放實(shí)體(也就是貧血模型聚居地)，dao自然是與數(shù)據(jù)庫或其他持久策略交互的地方，service作為整個(gè)應(yīng)用的核心，負(fù)責(zé)處理所有的邏輯，處理完成后交給dao做持久，controller起到調(diào)度的作用，其實(shí)就是一個(gè)個(gè)servlet。嘿嘿，熟悉吧，MVC模式。
《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中建議的，使用充血模型時(shí)的包結(jié)構(gòu)(更準(zhǔn)確的說是DDD的包結(jié)構(gòu))，如下圖：
這個(gè)解釋起來就比上一個(gè)要費(fèi)勁很多，用兩幅借來的圖解釋。
圖中就是DDD中的四層結(jié)構(gòu)，交互關(guān)系如下圖：
四層的職責(zé)分配：
其中值得注意的地方是，應(yīng)用的核心是領(lǐng)域?qū)印?/p>
呀，說了好多，也不知道大家是否能理解，估計(jì)看到這里都厭煩了吧。
稍微總結(jié)一下：我的體會(huì)是，貧血模型與充血模型之間的差別一定程度上造成了面向過程化編程和面向?qū)ο缶幊痰膬蓚€(gè)分支。那么差別到底是什么呢？說起來很簡單，就是業(yè)務(wù)邏輯由誰去處理。貧血模型僅僅被當(dāng)做數(shù)據(jù)結(jié)構(gòu)來使用，而充血模型會(huì)持有業(yè)務(wù)邏輯方法。
其次我們通過一個(gè)例子，展現(xiàn)一個(gè)貧血模型與充血模型中顯而易見的差別。
場景：一個(gè)網(wǎng)上銀行的簡單示例，要求可以存錢、取錢、轉(zhuǎn)賬、操作成功后需發(fā)送郵件給持卡人。要求提供貧血模型和充血模型兩種實(shí)現(xiàn)方式。(例子不是那么恰當(dāng)，網(wǎng)銀怎么取錢、存錢啊，只為說明問題。)
首先我們看下貧血模型是如何實(shí)現(xiàn)的。
類圖如下：
轉(zhuǎn)賬序列圖如下：
在交互的過程中，你會(huì)發(fā)現(xiàn)，核心確實(shí)是service層。
其他部分都省略，在圖中也能看個(gè)究竟，只貼出Account.java的代碼：
public class Account implements Serializable {
private static final long serialVersionUID = 2248636870918341727L;
private String accountNum;
private int totalAcount;
private String name;
private String cardNum;
//此處省略get、set方法
}充血模型的實(shí)現(xiàn)
類圖如下：
轉(zhuǎn)賬序列圖：
同樣貼出Account.java:
public class Account implements Serializable {
private static final long serialVersionUID = -4767597926507768285L;
private AccountRepository accountRepository;
private String accountNum;
private int totalAcount;
private String name;
private String cardNum;
public void deposit(int mony){
if(mony <= 0)
return;
this.totalAcount = this.totalAcount + mony;
accountRepository.updateAccount(this);
}
public void withdrawal(int mony){
if(mony <= 0)
return;
if(mony > this.totalAcount)
return;
this.totalAcount = this.totalAcount - mony;
accountRepository.updateAccount(this);
}
}不知道大家看出來區(qū)別了沒有，充血模型是有血有肉的，核心領(lǐng)域方法都放到模型去去，而不是把領(lǐng)域方法放到模型之上的service層中去。
引用別人對貧血模型和充血模型的總結(jié)(沒記錯(cuò)的話應(yīng)該是javaeye的robbin總結(jié)的)：
對于Java來說，更加適合采用貧血的模型，Java比較適合于把一個(gè)復(fù)雜的業(yè)務(wù)邏輯分離到n個(gè)小對象中去，每個(gè)小對象描述單一的職責(zé)，n個(gè)對象 互相協(xié)作來表達(dá)一個(gè)復(fù)雜的業(yè)務(wù)邏輯，這n個(gè)對象之間的依賴和協(xié)作需要通過外部的容器例如IoC來顯式的管理。但對于每個(gè)具體的對象來說，他們毫無疑問是貧 血的。
這種貧血的模型好處是：
1、每個(gè)貧血對象職責(zé)單一，所以模塊解藕程度很高，有利于錯(cuò)誤的隔離。
2、非常重要的是，這種模型非常適合于軟件外包和大規(guī)模軟件團(tuán)隊(duì)的協(xié)作。每個(gè)編程個(gè)體只需要負(fù)責(zé)單一職責(zé)的小對象模塊編寫，不會(huì)互相影響。
貧血模型的壞處是：
1、由于對象狀態(tài)和行為分離，所以一個(gè)完整的業(yè)務(wù)邏輯的描述不能夠在一個(gè)類當(dāng)中完成，而是一組互相協(xié)作的類共同完成的。因此可復(fù)用的顆粒度比較 小，代碼量膨脹的很厲害，最重要的是業(yè)務(wù)邏輯的描述能力比較差，一個(gè)稍微復(fù)雜的業(yè)務(wù)邏輯，就需要太多類和太多代碼去表達(dá)(針對我們假定的這個(gè)簡單的工時(shí)管 理系統(tǒng)的業(yè)務(wù)邏輯實(shí)現(xiàn)，ruby使用了50行代碼，但Java至少要上千行代碼)。
2、對象協(xié)作依賴于外部容器的組裝，因此裸寫代碼是不可能的了，必須借助于外部的IoC容器。
對于Ruby來說，更加適合充血模型。因?yàn)閞uby語言的表達(dá)能力非常強(qiáng)大，現(xiàn)在用ruby做企業(yè)應(yīng)用的DSL是一個(gè)很熱門的領(lǐng)域，DSL說白了就是用來描述某個(gè)行業(yè)業(yè)務(wù)邏輯的專用語言。
充血模型的好處是：
1、對象自洽程度很高，表達(dá)能力很強(qiáng)，因此非常適合于復(fù)雜的企業(yè)業(yè)務(wù)邏輯的實(shí)現(xiàn)，以及可復(fù)用程度比較高。
2、不必依賴外部容器的組裝，所以RoR沒有IoC的概念。
充血模型的壞處是：
1、對象高度自洽的結(jié)果是不利于大規(guī)模團(tuán)隊(duì)分工協(xié)作。一個(gè)編程個(gè)體至少要完成一個(gè)完整業(yè)務(wù)邏輯的功能。對于單個(gè)完整業(yè)務(wù)邏輯，無法再細(xì)分下去了。
2、隨著業(yè)務(wù)邏輯的變動(dòng)，領(lǐng)域模型可能會(huì)處于比較頻繁的變動(dòng)狀態(tài)中，領(lǐng)域模型不夠穩(wěn)定也會(huì)帶來web層代碼頻繁變動(dòng)。
好像在里面摻雜了好多東西，如果大家覺得羅嗦，可以看看這篇講領(lǐng)域模型的文章，比我寫的好，哈哈。鏈接在此：http://www./GandofYan/archive/2006/05/30/48954.html
其實(shí)僅僅就這個(gè)例子的兩種實(shí)現(xiàn)，還有太多太多的東西要去講，但不是本篇的重點(diǎn)。學(xué)海無涯啊，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)這方面的文章，在看書的過程中有任何感悟時(shí)我會(huì)陸續(xù)發(fā)到社區(qū)中。
