EF 的 POCO 与 POCO 更好的数据传输对象

本文关键字：POCO 对象数据传输 EF 更好 | 更新日期: 2023-09-27 18:36:48

我有一个场景，其中我在绑定到其UI的系统（桌面）中使用了一些自定义实体。我已经转向实体框架，因为它提供了好处，但将继续使用自定义实体从 UI 引入数据，因为自定义实体与系统紧密耦合。现在，如果我想消除系统对这些自定义实体的依赖，例如我想从 Web 或任何其他平台使用我的服务，从设计的角度来看，我有哪些选择？我认为要消除对自定义实体的依赖，我将不得不使用数据传输对象，例如 POCO。那么我应该使用 EF 为此目的提供的 POCO 实体还是单独编写它们？有意义吗。我应该采取什么方法。

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

认为实体框架实体是 POCO 样式域对象的代理，以便（例如）注入更改跟踪和延迟加载。此外，域对象包含的数据可能多于 UI 的某些部分所需的数据。

例如，您已经实现了一个包含 3 列的网格：名称、第二个名称和年龄。您将用户配置文件绑定到所谓的网格，但您的Profile域对象也具有更多属性，这将传输比 3 列网格所需的更多数据！

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

一个干净的体系结构将有一个包含 POCO 对象的类库程序集（我们称之为 Common）。根据定义，POCO 对象是持久性无关的，并且不包含任何行为。它们只是代表您的实体。

在单独的程序集（我们称之为 DataAccess）中，使用 DbContext 和 EntityTypeConfiguration<T> 类引用公共程序集并为 EntityFramework 创建映射。这显然意味着你不会使用任何 EDMX 文件，而是使用流畅的接口创建映射，这无论如何都是使用 EF 的最佳方式。

此时，一个程序集中具有可重用对象和解耦对象，另一个程序集中具有数据访问逻辑和映射。

最重要的是，您可以抛出一个 IoC 容器来使事情更加分离，但我认为这有点偏离主题。