當涉及到在.NET（Winforms，WPF，ASP.NET）上創建更大規模的企業級應用程序時，我看到兩個主要的「思想流派」。存儲庫模式與「智能」業務對象
一些人使用「存儲庫模式」，它使用知道如何獲取，插入，更新和刪除對象的存儲庫。這些對象相當「愚蠢」，因爲它們不一定包含大量的邏輯 - 例如他們或多或少是數據傳輸對象。
另一個陣營使用我稱之爲「聰明」的業務對象，知道如何加載自己，並且他們通常具有Save（），可能是Update（）或甚至Delete（）方法。這裏你真的不需要任何存儲庫 - 對象本身知道如何加載和保存自己。
很大的問題是：你使用哪一個或更喜歡哪一個？爲什麼？
您是否在所有應用程序中使用相同的方法，或者您有什麼特定的標準選擇一種方法嗎？如果是這樣 - 那些標準是什麼？
我並不是試圖在這裏開始一場火焰戰爭 - 試圖找出每個人對此的看法以及你的看法，以及爲什麼你使用一種（或兩種）模式。
感謝您的任何建設性意見！
由於單責任原則，我使用存儲庫模式。我不希望每個單獨的對象必須知道如何保存，更新和刪除自己，這可以通過單個通用存儲庫進行處理。
存儲庫模式不必導致啞對象。 如果對象在保存/更新之外沒有任何邏輯，則可能是在對象之外做了太多事情。
理想情況下，您不應該使用屬性從對象中獲取數據，計算東西並將數據放回對象中。這是封裝的一個突破。
所以對象不應該貧血，除非你使用簡單的DTO對象與CRUD操作。
然後，將持久性問題從您的對象關注點分離出來，是實現單一責任的好方法。
我認爲使用存儲庫模式與ActiveRecord模式最重要的副作用是測試和可擴展性。
沒有你的ActiveRecord對象包含一個存儲庫本身，你會如何隔離測試用例中的數據檢索？你不能真的假裝或嘲笑它。
除了測試以外，更換數據訪問技術也會困難得多，例如從Linq到SQL到NHibernate或EntityFramework（儘管這不會經常發生）。
這真的取決於應用程序的需求來了兩個有趣的文章，而是一個複雜的商業模式打交道時，我更喜歡的ActiveRecord。我可以在一個地方封裝（並測試）業務邏輯。
大多數ORM的（EF，nHibernate等等）作爲您的存儲庫。許多人認爲ORM之上的一層將所有數據交互封裝爲一個Repository，我認爲這是不正確的。據Martin Fowler稱，Repository將數據訪問作爲一個集合進行封裝。因此，對於所有數據檢索/變異可以使用數據映射器或數據訪問對象。
使用ActiveRecord，我喜歡有一個「實體」基類。我通常對這個基類使用ORM（存儲庫），所以我的所有實體都有一個GetById，AsQueryable，Save和Delete方法。
如果我正在使用更多的面向服務的體系結構，我將使用一個存儲庫（一個掩蓋直接數據訪問或的ORM）並直接在我的服務中調用它。
在這種情況下，一個通用知識庫需要知道如何加載所有類型的對象。 – 2009-05-20 16:26:45
，因爲它是通用的，它可以處理加載所有類型的對象。同時也使得單元測試更簡單 – 2009-05-20 16:29:49