在 .NET（Winforms、WPF、ASP.NET）上创建更大规模的企业级应用程序时，我看到了两个主要的“思想流派”。
有些人使用“存储库模式”，它使用知道如何获取、插入、更新和删除对象的存储库。这些对象相当“愚蠢”，因为它们不一定包含大量逻辑——例如，它们或多或少是数据传输对象。
另一个阵营使用我所谓的“智能”业务对象，它们知道如何加载自己，它们通常有一个 Save()、可能是 Update() 甚至是 Delete() 方法。在这里，您真的不需要任何存储库 - 对象本身知道如何加载和保存自己。
大问题是：您使用或喜欢哪个？为什么？
您是否在所有应用程序中使用相同的方法，或者您是否有任何特定标准何时选择一种方法而不是另一种？如果是这样 - 这些标准是什么？
我并不是想在这里发起一场激烈的战争——只是想了解每个人对此的看法以及您的意见，以及为什么您使用一种（或两种）模式而不是另一种模式。
感谢您的任何建设性意见！
由于单一职责原则，我使用存储库模式。我不希望每个单独的对象都必须知道如何保存、更新、删除自己，因为这可以由一个单一的通用存储库处理
存储库模式不一定会导致哑对象。如果对象在保存/更新之外没有逻辑，那么您可能在对象之外做了太多事情。
理想情况下，您永远不应该使用属性从对象中获取数据、计算事物并将数据放回对象中。这是封装的突破。
所以对象不应该是贫血的，除非你使用简单的 DTO 对象和 CRUD 操作。
然后将持久性关注点与对象关注点分开是拥有单一职责的好方法。
我认为使用 Repository 模式与ActiveRecord模式最重要的副作用是测试和可扩展性。
如果您的 ActiveRecord 对象不包含存储库本身，您将如何隔离测试用例中的数据检索？你不能轻易伪造或嘲笑它。
除了测试之外，交换数据访问技术也会变得更加困难，例如从 Linq-to-SQL 到 NHibernate 或 EntityFramework（尽管这并不经常发生）。
这确实取决于应用程序的需求，但是在处理复杂的业务模型时，我更喜欢 ActiveRecord。我可以在一个地方封装（和测试）业务逻辑。
大多数 ORM（EF、nHibernate 等）都用作您的存储库。许多人认为 ORM 之上的一层将所有数据交互封装为 Repository，我认为这是不正确的。根据 Martin Fowler 的说法，存储库将数据访问封装为一个集合。因此，为所有数据检索/变异提供单独的方法可能是使用数据映射器或数据访问对象。
使用 ActiveRecord，我喜欢有一个“实体”基类。我通常在这个基类中使用 ORM（存储库），所以我的所有实体都有 GetById、AsQueryable、Save 和 Delete 方法。
如果我更多地使用面向服务的架构，我将使用存储库（一个屏蔽直接数据访问或ORM 的存储库）并直接在我的服务中调用它。