实体框架与DTO我打算用EF（POCO）生成实体向客户端发送数据，而不是创建DTO？这是一个好习惯吗？基本上，我的EDMX文件在我的DAL层中。因此，UI可以直接访问我的DAL。谢谢。基本上，我不认为将DAL对象发送到您的界面是个好主意，所以我会使用DTO。为了尽量减少这样做，我会看一下DTO生成器，它生成DTO代码，允许您从DAL对象转换为DTO，反之亦然。编辑：抱歉，没看到你在使用POCO。看看这个SOpost这取决于客户端与对象域的距离。如果它是您的客户端，那么有可能-事实上这几乎就是ADO.NET数据服务（等）的工作方式-直接公开您的模型。但如果客户是其他任何东西，我建议使用专用的DTO。事实上，无论如何我都会建议它；否则，它会变得有点复杂：在大多数情况下，拥有一个单独的DTO将使大部分问题消失首先，我相信你不能在服务中使用实体框架生成的实体作为返回类型，至少在WCF服务。但是为什么要在整个应用程序中使用实体呢？如果你有一个带有客户端-服务器结构的通用架构，那么你的客户端将不需要EntityObject拥有的所有信息，比如包含它的ObjectContext、它的状态，以及你的客户端获得的许多其他信息不用，但更重要的是：不必知道。在这种情况下，您应该使用DTO模式或您认为更好的其他设计模式，以将服务器端与客户端分开。我相信DTO模式是最广泛使用和推荐的模式。如果您使用的是EntityFramework，您可以访问http://entitiestodtos.codeplex.com，这是我为VisualStudio和VisualStudio发布的，它是免费和开源的。它从您的实体框架数据模型(EDMX)生成您的DTO。真诚的，FabianFernandezDTO是一个很好的实践，可以最大限度地减少通过网络传输的数据量，并且只包含相关字段。这是其他好处之一。CheckoutAutomapper和ProjectTo方法可以自动将DAL转换为DTO，反之亦然。引擎盖下的项目只会选择配置映射中包含的列。https://github.com/AutoMapper/AutoMapper/wiki/Queryable-Extensions首先使用EntityFramework代码TT如《EntityFrameworkReversePOCOGenerator》（https://marketplace.visualstudio.com/items?itemName=SimonHughes.EntityFrameworkReversePOCOGenerator）在单独的业务实体模型库中生成与数据库表模式关联的业务模型。可以修改TT以专门将自定义属性（例如DataMember、Serializable）包含到WCF实体。这种方式可以同时拥有DTO和EFPOCO的优点。它使维护业务模型实体和数据库表之间的一致性变得容易。原因是对于大多数情况，任何时候修改数据库表结构，开发者也需要一个一致的业务模型结构（这里是DTO）。还有其他工作来维护映射器。如果数据库访问层模型（此处为EFPOCO）与DTO模型松散耦合。开发人员很难检测到编译时无法显示的潜在错误，它专门用于维护现有的企业级应用程序。如果我们有业务模型实体所需的其他自定义属性，我们可以添加具有自定义属性的分部类。我们仍然可以在需要时使用映射器将EFPOCO实体转换为DTO实体。但我的观点是，与将数据直接绑定到EFPOCO模型相比，尝试使用映射器可以减少滥用，这只是重复工作。由于我们可以在单独的业务模型存储库中生成EFPOCO实体，因此DTO实体可以将它们保存在同一个业务模型存储库中。因此，开发人员可以更灵活地决定如何使用它们。以上就是C#学习教程分享的全部内容：实体框架和DTO。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
