整理 POCO、Repository Pattern、Unit of Work 和 ORM答案

【问题标题】：Sorting out POCO, Repository Pattern, Unit of Work, and ORM整理 POCO、Repository Pattern、Unit of Work 和 ORM
【发布时间】：2011-06-01 09:49:45
【问题描述】：

我正在阅读所有这些主题的废话：

POCO
存储库模式
工作单位
使用 ORM 映射器

好的，我在书籍等中看到了每个的基本定义，但我无法将这些全部可视化。表示示例结构（DL、BL、PL）。

那又如何，你的 DL 对象包含你的 CRUD 方法，然后你的 BL 对象使用 ORM “映射”回你的 DL 对象？ DTO 怎么样……它们是你的 DL 对象，对吗？我很困惑。

谁能真正一起解释所有这些或将示例代码发送给我？我只是想把它放在一起。我正在确定是使用 LINQ to SQL 还是 EF 4（还不确定 NHibrernate）。

只是没有在这里了解物理层和代码层中的概念以及每种类型的对象包含的内容（只是 DTO 的属性，以及与表字段匹配的核心 DL 类的 CRUD ？？？）。

我只是需要一些指导。我正在阅读 Fowler 的书并开始阅读 Evans，但还不是全部。

【问题讨论】：

这里有很多问题；这让我很难回答。阅读更多内容（例如 Vsevolod 在他的回答中发布的链接），尝试一些概念，然后发布特定问题。然后我们可以更好地帮助您。在文学方面，我会说你走在正确的轨道上；但实际上：一次掌握的内容很多。

标签： c# linq-to-sql entity-framework orm domain-driven-design

【解决方案1】：

我将假设 DL - 领域层、BL - 业务层和 PL - 持久层。

如果您需要一个简单的 CRUD 应用程序，则不应使用 DDD 原则。如果要实现复杂的域模型，请使用 DDD。

在 DDD 中，您将 DL 和 BL 与域对象/服务中的所有逻辑相结合。否则，您将构建一个Anemic Domain Model。避免使用 setter 方法，仅通过方法调用来更改对象，例如 ChangeAddress 而不是 obj.Address = newAddress 或 Activate 而不是 obj.Active = true。

Data-Transfer-Objects 只能用于与外部服务/UI 的通信。在您的域内，您将只使用域对象。

我建议使用基于任务的 UI。

在持久层中使用什么持久性技术取决于您的要求。在您选择 SQL RDBMS 之前，请查看Object-relational impedance mismatch wikipedia 页面。

对于实施示例，请查看相关问题：

【讨论】：

太棒了，这正是我正在寻找的建议。现在，我知道有人为 .com 使用 LINQ to SQL 来存根他们的数据层 (DL) 类（crud 方法），然后使用存储库/工作单元模式来处理域逻辑和持久性。我的意思是他们有点同时使用我认为......这就是我在这里想要决定的。但是使用 DDD 不是很好吗？因为您没有将 BL（业务层）逻辑紧密绑定到持久层，所以我认为这对任何系统都有好处，但是您说使用 DDD 可能会影响性能？？
我曾为几个 .com 工作过，我们没有使用 DDD，只是通过编写自定义实体或类似 CodeSmith 模板的东西来将 DL 与 DB 紧密耦合以存根实体。但是现在我看到我采访过的地方都在 DDD 上发誓，而且都是电子商务 .com。我正在开发我自己的 .com，所以这就是为什么这一切对我来说都太过分了。我试图在这里变得更先进，以使我的应用程序更加灵活、干净和可扩展，而不是将严格的强对从 DL 到 DB...但是 DDD 将您的 BL 抽象为 DL 对?
@CoffeeAddict domain logic-repository/unit of work-LINQ to SQL - 如您所见，这里的存储库是一种抽象，允许您从域中隐藏持久性代码。这就是您最好使用存储库模式的原因。将此模式视为抽象层，而不是持久性技术。 DDD 并不是要将持久性与域分开。 DDD 是关于如何编写您的域代码。无处不在的语言，有限的上下文——这就是 DDD 的主要内容。为此，您必须将持久性与域分开。
@CoffeeAddict 你开始谈论性能——这是一个非常独立的话题，如果你真的需要快速的代码，你需要尽量减少为了执行某事而执行的方法调用次数。它将限制您分层代码的能力。但是，如果您真的有这样的要求，请三思。
@CoffeeAddict 是的，DDD 将您的 BL 抽象为 DL。但作为一种副作用。同样，DDD 是关于您如何组织与域相关的代码以使其更清洁并看起来更多业务如何理解它。因此，当域复杂时，DDD 是最好的。