wcf - 如果不再推荐自跟踪实体，那么更改跟踪复杂实体关系的前进道路是什么？

Question

自从EF首次出现以来，我一直在使用它。曾经在 3.5 中手动构建 POCO，很高兴在 EF4.0 中看到自跟踪实体 (STE)。

我在几个非常大的项目(500 多个实体，有些具有多个模型)中使用了 STE。在这些项目中，我使用通用存储库和通用工作单元来持久化实体，即 2 个没有映射的小型通用类。通过选择一个核心实体作为“聚合根”，在客户端添加和更新其他实体，并将包含这些更改的核心实体图发送到 WCF 服务并在创建 Repository<[core entity ]> 并使用 UnitOfWork<[core entity]>.Save(Repository<[core entity]>) 将 STE 及其子项持久化到数据库中。

现在 Microsoft 建议我们不要使用 STE。 See this article

所以我的问题是，Microsoft 现在为将客户端更改持久化到使用 EF 的 WCF 服务的应用程序推荐的模式是什么？

我创建了一个 EF5 模型并检查了生成的代码。 WCF 服务没有属性，即 DataContract、DataMember 等

EF4 有一个“ADO.NET DbContext Generator with WCF Support”模板，但没有等效的 EF5。

一个站点建议我应该使用部分类文件并使用这些属性装饰该文件中的相同属性。但除非 .net 4.5 引入了部分属性，否则我看不出如何做到这一点。

另一个 blog建议使用 DTO 和 Automapper，这意味着更多的映射容易出错；特别是当实体字段更改类型时。

所以现在 DBContext 生成的代码类没有启用服务，这是否意味着我们需要编写另一组类(POCO):

需要在查询数据库后从 DBContext 生成的代码类进行映射。

保存 WCF 服务客户端的数据状态

可由该客户更新

由客户端映射

具有保持更改状态的能力，因此可以将其发送回 WCF 服务

需要映射到 DBContext 生成的持久化代码类

似乎我们刚刚向 EF3 迈出了一大步。

如果您对在硬件上运行的客户端和服务进行编码，则无需担心客户端的数据结构，因为它们属于您。

如果你还需要向非 .NET 客户端公开你的一些服务方法，你应该对这些服务执行上述 5 点，并在这些情况下使用 DTO 和 Automapper。这些应该在不同的 WCF 服务中，但针对相同的逻辑实现图层，映射后。

但是，大多数软件团队在日常构建 Web 应用程序的过程中创建了多少此类非 .NET 客户端服务？

这个最新的建议令人困惑，因为它没有解释为什么 STE 总是考虑不周，现在推荐的模式是用于将客户端更改持久化到使用 EF 的 WCF 服务。

有人能告诉我在哪里可以找到解决这个架构设计问题的好资源吗？

附言

请不要推荐 WCF 数据服务或 WCF RIA，因为我们需要对客户端检索和保存数据的方式进行大量控制。

请不要推荐 Code First，因为我们使用 Database First，因为我们想要并且需要控制该数据库的结构，而不必为我们生成。

Answer 1

好的，所以当我第一次阅读这篇文章时，我也有同样的想法，像这样弃用 EF 的整个分支似乎有点奇怪，而且意图没有很好地传达(IMO)。我认为这里有几件事很重要:

本文中提到的 STE 是指基于对象上下文的自我跟踪实体(其行为有点像自主上下文)

ObjectContext 通常正在远离更清晰的 DbContext 结构(这适用于 DB First 和 Code First)

STEs != DB 第一代，您仍然可以在 EF 中使用 EDMX 模型，这不太可能改变。

当我最初看到这篇文章时，我将 STE 误认为仍然可用的 POCO 代理实体，并且 AFAIK 没有计划弃用。 (这些实现了对变更检测问题的类似技术解决方案，但具有更好的界面。查看本文以了解差异 EF4: Difference between POCO , Self Tracking Entities , POCO Proxies

那么，这意味着什么

基本上，就变更跟踪器的旧实现而言，STE 已被弃用，取而代之的是更新形式的变更跟踪( Snapshot 或 POCO Proxies )。这意味着如果快照跟踪不适合您，您应该查看类似于旧 STE 的 POCO 代理。

您仍然可以使用所有以前的技术来生成上下文(DB First、Model First、Code First 和 DB-> Code)