自从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):
似乎我们刚刚向 EF3 迈出了一大步。
如果您对在硬件上运行的客户端和服务进行编码,则无需担心客户端的数据结构,因为它们属于您。
如果你还需要向非 .NET 客户端公开你的一些服务方法,你应该对这些服务执行上述 5 点,并在这些情况下使用 DTO 和 Automapper。这些应该在不同的 WCF 服务中,但针对相同的逻辑实现图层,映射后。
但是,大多数软件团队在日常构建 Web 应用程序的过程中创建了多少此类非 .NET 客户端服务?
这个最新的建议令人困惑,因为它没有解释为什么 STE 总是考虑不周,现在推荐的模式是用于将客户端更改持久化到使用 EF 的 WCF 服务。
有人能告诉我在哪里可以找到解决这个架构设计问题的好资源吗?
附言
请不要推荐 WCF 数据服务或 WCF RIA,因为我们需要对客户端检索和保存数据的方式进行大量控制。
请不要推荐 Code First,因为我们使用 Database First,因为我们想要并且需要控制该数据库的结构,而不必为我们生成。
最佳答案
好的,所以当我第一次阅读这篇文章时,我也有同样的想法,像这样弃用 EF 的整个分支似乎有点奇怪,而且意图没有很好地传达(IMO)。我认为这里有几件事很重要:
那么,这意味着什么
基本上,就变更跟踪器的旧实现而言,STE 已被弃用,取而代之的是更新形式的变更跟踪( Snapshot 或 POCO Proxies )。这意味着如果快照跟踪不适合您,您应该查看类似于旧 STE 的 POCO 代理。
您仍然可以使用所有以前的技术来生成上下文(DB First、Model First、Code First 和 DB-> Code)
关于wcf - 如果不再推荐自跟踪实体,那么更改跟踪复杂实体关系的前进道路是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13924836/