在 DDD 中使用带有实体框架的另一个模型有什么好处答案

【问题标题】：What's the benefit of using another model with Entity Framework in DDD在 DDD 中使用带有实体框架的另一个模型有什么好处
【发布时间】：2010-09-13 18:46:32
【问题描述】：

在查看 DDD 的一些应用程序设计时，我发现从实体框架生成的对象仅用于访问数据存储。加载数据后，它会映射到应用程序模型中定义的另一个 POCO 对象。

这只是好的设计，是为了设计而做的吗？或者重新定义整个应用程序模型而不使用生成的对象是否有一些附加价值？如果是这样，如果你们中的任何人已经对此进行了一些研究，那么在应用程序的每一层中使用 EF 对象与使用不同的模型有什么优缺点？

MVC Storefront 是执行此操作的应用程序示例（即使它使用 LINQ to SQL），但它的想法相同。

谢谢！ :)

【问题讨论】：

标签： .net entity-framework architecture domain-driven-design

【解决方案1】：

关注点分离。 POCO 允许您在域模型中删除对 EF 的任何依赖。不太可能，但如果您在使用 EF 时遇到了技术难题，那么在切换到不同的 ORM/DAL 时影响会更小。

【讨论】：

这是唯一的优势吗，不是要破坏它，而是我从设计功能 POV 考虑，使用存储库的方式允许更可测试的应用程序？
Hatim - 从技术上讲你是对的，尽管它们通常一起实现分离和可测试性。存储库模式独立于 POCO。
Daz，我只是将存储库模式作为一个非常适合可测试性的架构特性的示例。但是我发现添加一个完整的模型有点太多了，以防我们使用的技术没有成功。似乎没有太多的工作。
“添加整个模型”无非就是运行 T4 模板。您不必编写任何额外的代码。

【解决方案2】：

该技术称为 DTO（数据传输对象），它完全断开了数据访问机制与系统任何其他部分的连接。

根据我的经验，使用实体对象（或者更好的是，EF4 中的 POCO，它具有 DTO 的许多优点）对于小型甚至可能是中型项目来说是完全可以的，但当然长期的可维护性更好POCO 和/或 DTO。

【讨论】：