在文章的開始,我先舉一個例子
　　美國M4謝爾曼坦克 VS德國的虎式坦克(相關(guān)資料如下http://mil.eastday.com/m/20070515/u1a2833237.html)

　　5：1 在五一期間，電視節(jié)目中的二戰(zhàn)武器大對決吸引了我，其中當美國大兵說他們在用5輛坦克的代價來換德國人的一輛虎式（I）型坦   克時，我們可以得出一個結(jié)論。蒙哥馬利和艾森豪威爾是在用二三十人的生命去換德軍的一輛坦克（而因為德軍坦克裝甲厚重，里面的架駛員得以逃生）。這是怎么一種自殺式的進攻呀！也許這么高的傷亡率在最終的勝利面前可能無所謂，但對于士兵([拯救大兵瑞恩])卻不完全是這么一回事了。而這里公司的CEO，或高層無疑也可以被視為這兩位偉人的化身。為了開發(fā)進度和用戶，他們可以強迫思維活越的程序員喪失創(chuàng)造力，因為他們需要的是能生成代碼的工人（相當于打仗的美國大兵）。而培養(yǎng)這些大兵的軍事訓(xùn)練所（軟件培訓(xùn)中心）也就成為源源不斷制造這種產(chǎn)品的工廠了。
   
　　這里不妨把OO域模型比做是虎式坦克，它在代碼結(jié)構(gòu),功能擴展（等同于火力），可維護性,可讀性 健壯性安全性（裝甲）等方面都是非常有優(yōu)勢的。但同時也出現(xiàn)了問題那就是機動性（太重太耗油,等同于學(xué)習(xí)成本），以及生產(chǎn)數(shù)量（等同于開發(fā)速度）成了這個優(yōu)秀設(shè)計思想的制約因素。因為具我了解OO設(shè)計會造成開發(fā)前期進度上的相對滯后，甚至搭一個框架所用的時間就已經(jīng)讓公司高級無法接受了。而同時一般公司又不愿意為這部分時間成功埋單, 因此程序員就想盡一切辦法（甚至生產(chǎn)垃圾代碼）來跟上開發(fā)進度。雖然有開源框架，代碼生成工具等來幫助提升代碼的質(zhì)量和開發(fā)速度，但本質(zhì)上這個項目它已經(jīng)成了一輛 "謝爾曼坦克"，它無法全面享受到OO所能提供的優(yōu)勢，而這里又不得不回頭用重構(gòu)等方法來改善代碼質(zhì)量了。（有些項目甚至連回頭的機會都沒有）

　　最終的結(jié)果是美國人說他們的坦克生產(chǎn)出20輛的時候，德軍那邊只有1輛下線。正是這種數(shù)量上的優(yōu)勢最終鎖定了美軍的在坦克戰(zhàn)上的勝局。

　　這個例子告訴我們這樣一個殘酷的事實，好的設(shè)計雖然能生產(chǎn)出好的軟件，但因為資源（時間，資金，人力等）要求過高。造成了一般企業(yè)或公司不想承擔(dān)。而這時貧血模型這類開發(fā)方式乘虛而入，用它們所標謗的優(yōu)勢和開發(fā)方式排演著一臺又一臺的鬧劇。

　　有些成功是激勵，而有些只是興奮劑甚至是毒藥。
　　因為今天我在這里所表達的觀點會招致相當多的人跳出來與我爭論，而不可避免的就是要拿出一堆成功的案例說這里用貧血模型實現(xiàn)的如何如何的好，項目進展如何如何等。
　　而我要說的就是當我們?yōu)椴捎秘氀蚰Ｐ投鬼椖?ldquo;成功”完成而沾沾自喜時，我們已經(jīng)在離經(jīng)叛道的路上越走越遠了。
　　做為一名程序員，到底是為誰去開發(fā)去編程。（A公司，B：為自己，C：為了民族軟件產(chǎn)業(yè)的振興D：為了共產(chǎn)主義理想等等。）
　　 當我們處在利益中心時，左側(cè)是項目經(jīng)理，技術(shù)經(jīng)理，產(chǎn)品經(jīng)理為首的公司方代表。 右側(cè)是用戶，客戶以及其它受眾。它們都想為了各自的利益一天到晚的在你身邊咆哮，要求你開發(fā)或修改這樣或那樣的代碼。表面上我們是項目的主宰，因為如果你沒完成工作，項目就不可以完成。但當我們進入設(shè)計開發(fā)階段后我們會因為資源的不夠使用而不得不做這樣或那樣式調(diào)整和妥協(xié)，最終大多數(shù)代碼都只是一味模式的照搬。這時就談不上什么將來產(chǎn)品要如何健壯如何好了。因為能對付過眼前摧命的各方勢力就已經(jīng)讓我們精疲力盡了。從這方面講我們已從“主宰”變成了“挨宰”。這時的我們已變成了稱鉈，要不停的調(diào)整自已在稱桿上的位置以適應(yīng)這些催命的人了種種要求。也許不少人這時拾起貧血模型這個稻草，起碼它會幫助我們節(jié)省設(shè)計和開發(fā)上的時間，項目最終可能也取得了成功。但當我們過上一段時間再回過頭看這些代碼，真不知道大家會做何敢想。

　　貧血模型（Fat Serviece）服務(wù)層成了一個框(此處存在筆誤已在回復(fù)中修正,敬請諒解!)，什么都往進裝（越來越臃腫）。本該是域模型中該有的邏輯，這時全被一股腦塞進了Business Logic。當業(yè)務(wù)邏輯復(fù)雜到一定程度時，就會有一些歸屬不明確的函數(shù)或?qū)傩猿鰜砹恕＿@些不明確的代碼相信有相當一部分要放在domain model中會更合理。但因為已經(jīng)貧血了，所以Business Logic成了它們的避護所。我給這些屬性或方法比做“難民”，有些難民可以還活在你的項目中，有些可能在使用一段時間后就死去了（系統(tǒng)不再使用，但未及時清理）。而如果這時公司又找來一個新人去接管這些代碼時，樂子可就大了。這就好比讓一個后媽去教育一個孩子，如盡心還好（會繼續(xù)有好的清楚的邏輯）在SERVICE中，而緩和這種矛盾。但多數(shù)程序員都不愿做后媽。因此這些方法就會像是沒有母親的孩子一樣如游魂野鬼一樣在你的項目中游蕩。　　

　　最后，學(xué)習(xí)成本的降低只能會造出更好與你相同的程序員甚至新人。因為貧血模型沒有充血模型那么復(fù)雜，實現(xiàn)起來很簡單，這就勢必造成一個事實，就是一個新入行幾個月的人很快也會用這個架構(gòu)去搞程序開發(fā)。這種自貶身價的結(jié)果最終可能導(dǎo)致的情況就是當某天工作結(jié)束時，你會發(fā)現(xiàn)你身邊的同時有可能就是一只pig or cow。

　　好了，文章寫完了，我已經(jīng)開始準備挨罵了，不過無所謂，希望大家勇躍拍磚!

it知識庫：域模型向左走(充血)，向右走(貧血)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。