entity framework和DTO
我打算使用EF（POCO）生成的实体向客户端发送数据而不是创建DTO？ 这是一个好习惯吗？ 基本上，我的EDMX文件在我的DAL层。 因此，UI可以直接访问我的DAL。 谢谢。
基本上，我不认为将DAL对象发送到您的界面是个好主意，所以我会使用DTO。 为了最大限度地减少这样做，我将看一下DTO生成器 ，生成DTO代码，它允许您从DAL对象转换为DTO，反之亦然。
编辑：对不起，没看到你正在使用POCO。 看看这篇SOpost
这取决于客户端与对象域的接近程度。 如果它是您的客户 ，那么可能 – 实际上这几乎是ADO.NET数据服务（等）如何工作 – 直接暴露您的模型。
但是，如果客户是其他任何我建议专用的DTO。 事实上，无论如何我都会建议它;否则，它会变得有些复杂：
- 控制序列化细节（什么成员？什么名字？当我们发布它时会发生什么？）
- 处理关系属性（它有一个
Orders成员……但是是懒惰加载了吗？我们想要吗？） - 将传入对象（用于更新等）合并回模型
- 在反序列化期间，抑制您在setter等中添加的任何逻辑
- 如果在基于树的序列化程序（如
DataContractSerializer中获得同一对象的2个单独副本，则处理身份管理
在大多数情况下，拥有一个单独的DTO会使大部分问题消失
首先，我相信您不能将entity framework生成的实体用作服务中的返回类型，至少在WCF服务中是这样。
但是，为什么要在整个应用程序中使用实体？ 如果您有一个具有客户端 – 服务器结构的通用体系结构，那么您的客户端将不需要EntityObject具有的所有信息，例如包含它的ObjectContext，其上的状态以及您的客户端的许多其他信息不会使用，但更重要的是：不必知道。
在这种情况下，您应该使用DTO模式或您认为更好的其他设计模式，将服务器端与客户端分离。 我相信DTO Pattern是最广泛使用和推荐的。 如果您使用的是Entity Framework，可以访问http://entitiestodtos.codeplex.com ，它是我发布的Visual Studio和Visual Studio，它是免费的开源软件。 它从您的entity framework数据模型（EDMX）生成您的DTO。
此致，Fabian Fernandez
DTO是一种很好的做法，可以最大限度地减少通过网络传输的数据量，只包含相关字段。 这是其他好处之一。 Checkout Automapper和ProjectTo方法，它可以自动将DAL转换为DTO，反之亦然。 项目引擎盖下的项目只会选择已配置映射中包含的列。
https://github.com/AutoMapper/AutoMapper/wiki/Queryable-Extensions
首先使用实体框架代码TT，例如“EntityFramework Reverse POCO Generator”（ https://marketplace.visualstudio.com/items?itemName=SimonHughes.EntityFrameworkReversePOCOGenerator ），以在单独的业务实体模型库中生成与数据库表模式关联的业务模型。 可以修改TT以特别向WCF实体包括自定义属性（例如DataMember，Serializable）。
这种方式可以同时具有DTO和EF POCO的优点。 它可以轻松地保持业务模型实体和数据库表之间的一致性。
原因是，对于大多数情况，任何时候修改数据库表结构，开发人员还需要一致的业务模型结构（这里是DTO）。 还有其他工作来维护映射器。
如果数据库访问层模型（这里的EF POCO）与DTO模型松散耦合。 开发人员很难检测到编译时间无法显示的潜在错误，专门用于维护现有的企业级应用程序。
如果我们有业务模型实体所需的其他自定义属性，我们可以添加具有自定义属性的部分类。
我们仍然可以使用映射器在需要时将EF POCO实体转换为DTO实体。 但我的观点是，与直接将数据绑定到EF POCO模型相比，尽量使用mappers来减少滥用，这只是做重复工作。
由于我们可以在独立的业务模型库中生成EF POCO实体，因此DTO实体可以将它们保留在同一个业务模型库中。 因此，开发人员可以更灵活地决定如何使用它们。