如果不再推荐自我跟踪实体,那么改变复杂实体关系的前进道路是什么？

Question

自从它首次问世以来,我一直在使用EF.用于在3.5中手动构建POCO,很高兴看到EF4.0中的自跟踪实体(STE).

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

现在微软建议我们不要使用STE.看到这篇文章

所以我的问题是,对于那些将客户端更改持久保存到使用EF的WCF服务的应用程序,Microsoft现在推荐的模式是什么？

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

EF4有一个"支持WCF的ADO.NET DbContext生成器"模板,但没有EF5等价物.

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

另 一篇博客 建议使用DTO和Automapper,这意味着更多的映射容易出错; 特别是当实体字段改变类型时.

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

• 在查询数据库之后,需要从DBContext生成的代码类映射.
• 保存WCF服务客户端的数据状态
• 可由客户端更新
• 由客户映射
• 能够保持更改状态,以便将其发送回WCF服务
• 需要映射到DBContext生成的代码类以实现持久性

看起来我们刚刚向EF3迈进了一大步.

如果您对在硬件上运行的客户端和服务进行编码,则无需担心客户端属于您的数据结构.

如果您还需要向非.NET客户端公开一些服务方法,那么无论如何都应该为这些服务执行上述5点,并在这些场合使用DTO和Automapper.这些应该在不同的WCF服务中,但是针对相同的逻辑实现图层映射后.

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

这个最新的建议令人困惑,因为它没有被解释为什么STE总是构思错误,现在是什么,建议的模式用于持久化客户端更改使用EF的WCF服务.

任何人都可以告诉我哪里可以找到解决这个架构设计问题的好资源？

PS

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

请不要推荐Code First,因为我们使用Database First,因为我们希望拥有并且需要控制该数据库的结构而不必为我们生成.

Answer 1

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

• 本文中提到的 STE 是指基于对象上下文的自跟踪实体（其行为有点像自治上下文）
• 通常会放弃 ObjectContext，转而采用更干净的 DbContext 结构（这适用于数据库优先和代码优先）
• STE != DB 第一代，您仍然可以在 EF 中使用 EDMX 模型，并且这一点不太可能改变。
• 当我最初看到这篇文章时，我将 STE 误认为是仍然可用的 POCO 代理实体，据我所知，没有计划弃用。（这些实现了与变更检测问题类似的技术解决方案，但具有更好的界面。查看本文以了解差异EF4：POCO 、自跟踪实体、POCO 代理之间的差异

那么，这意味着什么

基本上，旧的变更跟踪器实现方面的 STE 已被弃用，取而代之的是更新形式的变更跟踪（快照或POCO 代理）。这意味着，如果快照跟踪不适合您，您应该考虑与旧 STE 类似的 POCO 代理。

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