失血模型，充血模型

1、失血模型 

失血模型簡單來講，就是domain object只有屬性的getter/setter方法的純數據類。

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

這種模型的優勢： 
一、各層單向依賴，結構清楚，易於實現和維護 
二、設計簡單易行，底層模型很是穩定 

這種模型的缺點： 
一、domain object的部分比較緊密依賴的持久化domain logic被分離到Service層，顯得不夠OO 
二、Service層過於厚重

從優缺點來看，簡單穩定易維護是失血模型的最大優勢，缺點顯得不夠面向對象，確實是不夠面向對象，可是對於中小型項目，業務邏輯並非很複雜，更多的需求在於穩定運行於可維護擴展，

顯然利稍大玉弊，並且此模型結合ORM實現CodeFirst，能夠實現快速開發，節省人力和成本，更是中小行項目所青睞的，那麼何樂而不爲呢。並且這種模型應該根據項目須要來進行調整和修改

不可生搬硬套。

例如咱們搞的商城，爲了減輕各環節服務器的壓力，下降各業務以前的耦合，提升業務模塊的複用性。簡單的畫了張圖，這樣實現項目須要和替換原有模塊上都能方便的實現。

嗯，這裏就不得不加一句，符合需求的設計纔是最合理的。

 1、充血模型

 充血模型和貧血結構上差很少,不一樣的是它把大部分與本身相關領域的行爲或者邏輯放到領域對象裏面了,而業務層或者Service中只有少許的邏輯,簡單日誌,權限,事務等,這樣層次結構就變成Client->（Business Facade)->Business Logic->Domain Object->Data Access。   這種模型的優勢： 一、更加符合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層程序員的角度來看，和貧血模型沒有什麼區別了。