.net 什么'；在DDD中使用另一个实体框架模型的好处是什么

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

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

MVC Storefront就是这样一个应用程序的例子（尽管它使用LINQ to SQL），但它的思想是相同的

---

谢谢！：）

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

---

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

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

这是唯一的优势，不是破坏它，但我是从设计功能的角度考虑的，使用存储库的方式允许一个更可测试的应用程序？Hatim-从技术上讲，您是正确的，尽管它们通常都一起实现分离，从而实现可测试性。repository模式独立于POCO.Daz，我刚刚给出了repository模式作为一个非常有助于可测试性的架构特性的示例。但我发现，为了防止我们使用的技术无法成功，添加一个完整的模型有点太多了。“添加一个完整的模型”只不过是运行T4模板。您不必编写任何附加代码。