貧血模型和充血模型

貧血模型：是指領域對象裏只有get和set方法，或者包含少許的CRUD方法，全部的業務邏輯都不包含在內而是放在Business Logic層。
優 點是系統的層次結構清楚，各層之間單向依賴，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。固然Business Logic是依賴Domain Object的。彷佛如今流行的架構就是這樣，固然層次還能夠細分。
該模型的缺點是不夠面向對象，領域對象只是做爲保存狀態或者傳遞狀態使用，因此就說只有數據沒有行爲的對象不是真正的對象。在Business Logic裏面處理全部的業務邏輯，在POEAA(企業應用架構模式)一書中被稱爲Transaction Script模式。

充血模型： 層次結構和上面的差很少，不過大多業務邏輯和持久化放在Domain Object裏面，Business Logic只是簡單封裝部分業務邏輯以及控制事務、權限等，這樣層次結構就變成Client->（Business Facade)->Business Logic->Domain Object->Data Access。
優勢是面向對象，Business Logic符合單一職責，不像在貧血模型裏面那樣包含全部的業務邏輯太過沉重。
缺 點是如何劃分業務邏輯，什麼樣的邏輯應該放在Domain Object中，什麼樣的業務邏輯應該放在Business Logic中，這是很含糊的。即便劃分好了業務邏輯，因爲分散在Business Logic和Domain Object層中，不能更好的分模塊開發。熟悉業務邏輯的開發人員須要滲透到Domain Logic中去，而在Domian Logic又包含了持久化，對於開發者來講這十分混亂。  其次，由於Business Logic要控制事務而且爲上層提供一個統一的服務調用入口點，它就必須把在Domain Logic裏實現的業務邏輯所有從新包裝一遍，徹底屬於重複勞動。

若是技術可以支持充血模型，那固然是最完美的解決方案。不過如今 的.NET框架並無ORM工具（不算上開源的NHibernate，Castle之類），沒有ORM就沒有透明的持久化支持，在Domain Object層會對Data Access層構成依賴，若是脫離了Data Access層，Domain Object的業務邏輯就沒法進行單元測試，這也是很致命的。若是有像Spring的動態注入和Hibernate的透明持久化支持，那麼充血模型仍是能 夠實現的。