POCO 类应该包含方法吗？如果是，它们与域对象有何不同？ [关闭]

Question

好的，所以我一直在尝试绕过domain driven development (DDD).

我知道POCO 类应该很简单，并且它们与实体框架没有任何联系。当需要任何数据库操作时，这些类将映射到实体。

我还知道在 DDD 中，您的类中包含所有业务逻辑。

我的问题是，如果我开始将逻辑和方法放入我的 POCO 类中，它们将不再简单，但如果我开始分别创建和使用我的域类，我需要先将我的域对象映射到POCO 然后POCO 对象到实体对象，反之亦然，这变得越来越忙。

所以我应该像这样：Entities <--> POCO (Simple class) <--> Domain Object (All business logic) 还是应该摆脱 POCO 类而只使用域类，因为我正在完成工作，包括 BL 和 EF 实体之间的层分离。

谢谢。

Answer 1

根据定义，POCO 内部没有任何逻辑。它们主要是一个持有者类，只包含各种字段和属性。一旦开始向其中添加逻辑，您就开始在领域驱动设计的道路上走得更远。

许多开发人员，如 Martin Fowler，正确地认为 POCO 的广泛使用会导致 Anemic Domain Model，Wikipedia 将其定义为：“......使用软件域模型，其中域对象包含很少或不包含业务逻辑”。在我看来，如果您不采取积极措施来减轻它，那么在使用 EF 时出现贫血模型绝对是一个真正的风险。

这并不是说每个为实体使用 POCO 的系统都注定会产生 ADM。事实上，Jason Taylor 有一个关于 Clean Architecture 的 amazing talk，他的 Northwind Traders demo 展示了一些很好的方法，可以在不牺牲清晰度的情况下潜在地分割您的应用程序。

现代实体框架核心非常适合两种设计范式（POCO 和 DDD），因此确实没有“正确”的答案。我个人在我的大多数重要用例中都采用混合方法。我的实体模型包含实体的硬性和快速的通用域规则；不要与域逻辑混淆。我的领域层包含大部分相关领域逻辑，或者更确切地说，各种实体如何相互交互。我的应用层将所有内容整合在一起，它包含负责使程序运行的实际逻辑。

我仍然有 POCO，但它们主要用于在客户端之间传输数据。我将它们与AutoMapper 和FluentValidation 结合使用以简化样板代码，但它们绝不是必需的。

---

所以当谈到 POCO 问题时，答案是：“视情况而定”。