我有一个场景，我在系统（桌面）中使用了一些自定义实体绑定到其UI。我已经转移到Entity框架以获得它提供的好处，但是随着自定义实体与系统紧密耦合，我将继续使用自定义实体从UI引入数据。 现在，如果我想删除系统对这些自定义实体的依赖性，比如说我想从网络或任何其他平台使用我的服务，那么从设计角度来看，我有哪些选择？ 我认为要消除对自定义实体的依赖，我将不得不使用数据传输对象说POCO。 那么我应该使用EF为此目的提供的POCO实体还是单独写它们？ 是否有意义。我的方法应该是什么。
答案 0 :(得分：1)
即使域对象实现为 POCO ，它们仍然是域对象，不应使用DTO转移到其他物理层。
Think Entity Framework实体是POCO样式域对象的代理，以便 - 例如 - 注入更改跟踪和延迟加载。此外，域对象可能包含的数据超出了UI的某些部分所需的数据。
例如，您已经实现了一个包含3列的网格：名称，名字和年龄。您将用户配置文件绑定到所谓的网格，但您的Profile域对象还具有更多属性，这将传输比3列网格所需的更多数据！
这就是为什么您希望将域名保留在您的域中，并且您的服务发出的数据将序列化DTO以涵盖您的实际UI用例，并且您不会传输胖对象通过电线，可能会给您的组织增加额外的成本（通常是您在托管环境中为网络使用付费），显然，序列化小对象的密集程度较低，不是吗？
答案 1 :(得分：0)
干净的体系结构将包含一个包含POCO对象的类库程序集（我们称之为Common）。根据定义，POCO对象是持久性无知且不包含任何行为。它们只代表您的实体。
在一个单独的程序集中（我们称之为DataAccess）引用Common程序集，并使用DbContext和EntityTypeConfiguration<T>类为EntityFramework创建映射。这显然意味着您不会使用任何EDMX文件，而是使用流畅的界面创建映射，这无论如何都是使用EF的最佳方式。
此时，您在程序集中具有可重用和分离的对象，并且您的数据访问逻辑和映射在另一个程序集中。
除此之外，您可以抛出一个IoC容器以使事情更加分离，但我认为这有点偏离主题。