在查看DDD的一些应用程序设计时,我看到实体框架生成的对象仅用于访问数据存储。加载数据后,它将映射到应用程序模型中定义的另一个POCO对象。
这只是一个好的设计并且是为了设计而完成的吗?或者是否有一些附加值来重新定义整个应用程序模型而不使用生成的对象?如果是这样,如果您已经对此进行过一些研究,那么在应用程序的每一层中使用EF对象与使用不同模型的优缺点是什么?
MVC Storefront是一个应用程序的例子(即使它使用LINQ to SQL),但它的想法是一样的。
谢谢! :)
答案 0 :(得分:2)
关注点分离。 POCO允许您删除域模型中对EF的任何依赖性。不太可能,但如果你使用EF打一个技术砖墙,那么切换到不同的ORM / DAL时影响会更小。
答案 1 :(得分:1)
该技术称为DTO(数据传输对象),它完全断开了数据访问机制与系统其他任何部分的连接。
根据我的经验,使用实体对象(甚至更好,EF4中的POCO具有DTO的许多优点)对于小型甚至可能是中等项目来说都是非常好的,但当然长期的可维护性更好POCO和/或DTO。