c# - EF 的 POCO vs POCO 更好的数据传输对象？

Question

我有一个场景，其中我有一些自定义实体在绑定(bind)到其 UI 的系统(桌面)中使用。我已经转向 Entity Framework 以获得它提供的好处，但由于自定义实体与系统紧密耦合，我将继续使用自定义实体从 UI 获取数据。现在，如果我想消除系统对这些自定义实体的依赖，比如我想从网络或任何其他平台使用我的服务，从设计角度来看我有哪些选择？我认为要消除对自定义实体的依赖，我将不得不使用数据传输对象，比如 POCO。那么我是应该使用 EF 为此提供的 POCO 实体还是单独编写它们？是否有意义。我的方法应该是什么。

Answer 1

即使域对象被实现为POCO，它们仍然是域对象，不应该在不使用 DTO 的情况下转移到其他物理层。

Think Entity Framework 实体是您的 POCO 风格域对象的代理，以便 - 例如 - 注入(inject)更改跟踪和延迟加载。此外，域对象可能包含比 UI 某些部分所需的更多数据。

例如，您实现了一个包含 3 列的网格:姓名、姓氏和年龄。您将用户配置文件绑定(bind)到所谓的网格，但您的 Profile 域对象也有更多属性，这将传输比您的 3 列网格所需的更多数据!

这就是为什么您希望将您的域保留在您的域中，并且您的服务发出的数据将序列化 DTO 以涵盖您的实际 UI 用例，并且您不会通过网络传输胖对象，这可能会增加额外的费用您的组织成本(通常您为托管环境中的网络使用付费)，显然，序列化小对象的强度较低，不是吗？