是指領域物件裡只有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的透明持久化支援，那麼充血模型還是能夠實現的。
選擇了.net平台開發，就是選擇了開發高效、功能強大應用簡單，最適合的模型就是貧血模型，或表資料入口，既有編譯器和語言平台很好的支援，也符合微軟提倡的開發模式。如果跟潮流在專案中使用充血模型，現有的orm工具都很複雜難用，光是維護大量的對映檔案都成問題。說貧血不夠oo，它的domain object不夠豐富，能把專案做好了，有一定的擴充套件能力和伸縮行就行了，也不一定要講究優雅的物件導向。正如soa，講究松耦合、高內聚，服務端給客戶端提供的服務，也就是一系列的方法呼叫加上dto而已，不管服務的內部是不是物件導向的實現，至少它暴露出來的是過程式的服務。
你真的物件導向了嗎？充血模式和貧血模式
還記得我們剛開始學物件導向的時候嗎？物件裡面有什麼？屬性和行為。但時至今日，我們的物件只有屬性，何來行為一說呀！充血模式和貧血模式 貧血模型 是指領域物件裡只有get和set方法，或者包含少量的crud方法，所有的業務邏輯都不包含在內而是放在business logic層。優點是系統的層次結構清楚，...
設計模式 物件導向七 貧血模型與充血模型
前景 我們都知道，現在很多專案都是基於貧血模型的mvc三層框架。雖然這種開發模式已經成為了標準的web專案的開發模式，但是它卻違反了物件導向的程式設計風格，是一種徹底的面向過程的程式設計風格，因此有人稱之為反模式。什麼是mvc mvc三層架構中，m表示model，v表示view，c表示control...
貧血模型和充血模型
這兩個概念是早些時候martin fowler總結出來的兩種常見模型設計型別，沒有說誰好誰不好，為不同的模型類別選擇合適的場景是設計者的工作。沒有工具本身的問題，只有工具使用者的問題。貧血模型是指領域物件裡只有get和set方法 pojo 所有的業務邏輯都不包含在內而是放在business logi...