design-patterns - POCOs != 域对象？

Question

当我使用 ORM 完成我的第一个大型项目时，我开始意识到 ORM 将成为创建具有表现力和传达意图的域对象的一大障碍。

也就是说，我知道我们不希望域对象仅仅是可公开访问的 getter 和 setter 的袋子。此外，我开始意识到，仅仅让 IList 到处都是并不能传达意图，并且可能会招致使用这些对象的开发人员的滥用。例如，也许最好公开 ReadOnlyCollection。 (顺便说一下，我正在使用 .NET 和 Entity Framework 。)而不是 IList，我发现自己想要公开一个对象列表 派生 从我的域对象。 (这些事情在 EF 中都不容易做到。也许我需要使用 NHibernate 或 ADO.Net。)

我的问题是:我尝试以这种方式制作领域对象是否太过分了？这些问题应该只是其他应用程序组件的一部分吗？或者我应该有一个“真正的”域对象(具有表现力的东西)和一个由 ORM 水合的“哑巴”POCO 对象？

(编辑:系统吃了一堆我的尖括号。)

Answer 1

我的观点是你让 EF 做它的事情并创建免费赠品 POCO。您也可以称它们为 DTO——它们的作用是充当从内存到持久性再返回的桥梁。就您的“域”而言，我从未相信您的数据库架构反射(reflect)了一致的域模型。因此，我总是在代表业务领域的 Persistence(或存储库)层之上创建一个 Domain 层，将 Persistence 的香肠工厂排除在外。该领域层可以根据需要混合您的 DTO，以创建一个有意义的面向开发人员的模型。使用工厂模式从 DTO 创建域对象，反之亦然 - 将 DTO 保留在客户端代码之外，以便您可以将架构更改与使用者隔离。

这是更多的工作，更多的映射代码等，但这是值得的 - EF 已经减少了您的代码，我认为您实际上应该花时间对域逻辑和表示进行编码，这使您比代码生成工具更好: )

祝你好运。