自从EF问世以来，我一直在使用它。曾在3.5中手工构建POCO，很高兴在EF4.0中看到自跟踪实体(STE)。
我在几个非常大的项目中使用过STE(500多个实体，有些有多个模型)。在这些项目中，我使用通用存储库和通用工作单元来持久化实体，即2个没有映射的小通用类。通过选择核心实体作为"聚集根"，在客户端添加和更新其他实体，并将包含这些更改的核心实体图发送到WCF服务，并在创建Repository<[核心实体]>并使用UnitOfWork<[核心实体]>。保存(Repository<[core entity]>)以将STE及其子级持久保存到数据库中。
现在微软建议我们不要使用STE。参见本文
因此，我的问题是，对于那些将客户端更改持久化为使用EF的WCF服务的应用程序，Microsoft现在推荐的模式是什么？
我创建了一个EF5模型，并检查了生成的代码。WCF服务没有属性，即DataContract、DataMember等
EF4有一个"ADO.NET DbContext Generator with WCF Support"模板，但没有等效的EF5。
一个网站建议我应该使用分部类文件，并用这些属性装饰该文件中的相同属性。但是，除非.net 4.5引入了部分属性，否则我看不出如何做到这一点。
另一个博客建议使用DTO和Automapper，这意味着更容易出错的映射；尤其是当实体字段更改类型时。
既然DBContext生成的代码类没有启用Service，这是否意味着我们需要编写另一组类(POCO)：
查询数据库后，需要将- 从DBContext生成的代码类映射
- 保存WCF服务客户端的数据状态
- 可由该客户端更新
- 由客户端映射
- 能够保持更改后的状态，以便将其发送回WCF服务
- 需要映射到DBContext生成的代码类以实现持久性
我们似乎刚刚向EF3迈出了一大步。
如果您对在硬件上运行的客户端和服务都进行了编码，则不需要关心客户端的数据结构，因为它们属于您。
如果您还需要将一些服务方法公开给非。NET客户端，您应该为这些服务执行上面的5点，并在这些情况下使用DTO和Automapper。这些应该在不同的WCF服务中，但在映射后针对相同的逻辑层实现。
但是这些类型的非有多少。NET客户端服务是在大多数软件团队的日常web应用程序构建中创建的吗？
这一最新建议令人困惑，因为它没有解释为什么STE总是考虑不周，以及现在建议使用什么模式来持久化使用EF的WCF服务的客户端更改。
有人能告诉我在哪里可以找到解决这个建筑设计问题的好资源吗？
第页。S.
请不要推荐WCF数据服务或WCF RIA，因为我们需要对客户端检索和保存数据的方式进行大量控制。
请不要推荐"代码优先"，因为我们使用"数据库优先"，这是我们想要的，并且需要控制该数据库的结构，而不必为我们生成。
好吧，所以当我第一次读这篇文章时，我也有同样的想法，像这样贬低EF的整个分支似乎有点奇怪，而且意图没有得到很好的传达(IMO)。我认为有几件事很重要：
本文中提到的STE是指基于对象上下文的自跟踪实体(其行为有点像自主上下文)那么这一切意味着什么
基本上，STE在旧的变更跟踪器实现方面被弃用，取而代之的是更新形式的变更跟踪(快照或POCO代理)。这意味着，如果快照跟踪不适合您，您应该查看与旧STE类似的POCO代理。
您仍然可以使用所有以前的技术来生成上下文(DB First、Model First、Code First和DB->Code)