還記得我們剛開始學物件導向的時候嗎？物件裡面有什麼？屬性和行為。但時至今日，我們的物件只有屬性，何來行為一說呀！
充血模式和貧血模式
貧血模型：是指領域物件裡只有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而已，不管服務的內部是不是物件導向的實現，至少它暴露出來的是過程式的服務。
感謝：充血模式和貧血模式
JS物件導向 你真的理解閉包了嗎？
js中的閉包，可能在實際開發中我們用的很少，但是面試的時候是必問的。所以今兒個總結一下什麼是閉包。首先，我們定義乙個變數。會分為兩種情況，1是定義在全域性中，我們關閉程式的時候變數會從記憶體中釋放。2是定義在區域性中，在函式中定義乙個變數，當我函式呼叫結束後，會從記憶體中釋放。閉包的存在，就是為了當...
今天，你物件導向了嗎？
關於武術絕招 我的武術老師告訴我他的絕招就是直拳，而且從第一天開始他就告訴我每天不低於五千次的訓練，當我把這個直拳練到非常快速的時候，這就是絕招了。開始我根本 不相信老師交給的絕招。後來在南韓練跆拳道，與世界第一號種子選手對話，才恍然大悟老師的話 他們把簡單的動作練的不可替代，而往往簡單的動作就是最...
物件導向，你入門了嗎？
我所接觸的程式設計師中，大約80 以上的人都在談物件導向 oo 當然大多數人談的都是物件導向程式設計 oop 談ooa ood的也有，不過好像很少！特別是在物件導向的三要素 封裝 繼承 多型 上更是說得頭頭是道，可是很奇怪 一旦叫他們用物件導向設計一套系統，這些人往往不知道從什麼地方開始了！物件導向...