将实体框架自动生成的实体映射到数据传输对象？

Question

使用Entity Framework 4.1将自动生成的实体框架实体映射到适合数据传输的对象的最佳方法是什么？

我正在使用的内容如下：

WPF Application -> WCF Service -> Entity Framework (DAL) -> Database

除了WPF应用程序之外，WPF应用程序可以在某些时候交换到ASP.NET网站。因此使用WCF服务。

WCF服务，数据库和实体框架代码都将位于同一物理层。

在以前版本的Entity Framework（之前的4.0版）中，我相信您必须为您的类编写自己的映射代码。现在有更好的方法吗？

另外一个问题是，在执行业务逻辑的DTO中包含方法会是不好的做法吗？在这种情况下，哪里是应用业务逻辑的最佳位置？

Answer 1

从EF实体映射到DTO的最佳方法是project。我在那里链接的例子使用的是视图模型而不是DTO，但这个想法是一样的。

对于大多数包含EF的ORM，如果您只需要DTO，那么实现您不需要支付的实体需要付出代价。费用包括：

• Fixup - 当两个对象引用同一个相关对象时，请确保它们指向同一个实例。
• 跟踪 - 在上下文中跟踪实例的开销。
• 不必要的列 - 您可能不需要DTO的所有属性。
• 聚合 - 像.Count()这样的函数在SQL中比在对象空间中效率更高。

如果您使用L2E投影，则不会产生此成本的任何。如果您按照常见建议使用AutoMapper锤子来处理看起来像钉子的每个问题，那么您需要支付所有。

我同意@sternr关于不在实体/ DTO上放置方法的观点。有关此想法的更详细检查，请阅读“At the Boundaries, Applications are Not Object-Oriented。”

Answer 2

使用AutoMapper在简单DTO和EF实体之间进行映射

[编辑：]了解您的其他问题：

对于映射：您可以使用内置的edmx设计器，它允许您使用现有的数据库模式来生成模型实体，或者反过来（定义您的实体，让EF创建您的DDL）。登记/> 较新的版本（从4.1开始）您可以简单地对实体进行编码并在相关属性上添加DataAnnotations，EF将执行魔术映射（here's a good sample）

至于向DTO添加逻辑，根据他们的定义，DTO是一个数据联系人 - 消费者可能会创建它自己的实现（通过自动代理或其他手动包装器），所以在它们中放置逻辑有点使毫无意义。