5

自从 EF 刚问世以来，我就一直在使用它。曾经在 3.5 中手动构建 POCO，很高兴在 EF4.0 中看到自跟踪实体（STE）。

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

现在 Microsoft 建议我们不要使用 STE。看这篇文章

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

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

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

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

另一个 博客 建议使用 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，因为我们希望拥有并且需要控制该数据库的结构，而不必为我们生成。

4

1 回答 1

0

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

  • 本文中提到的 STE 指的是基于对象上下文的自我跟踪实体（其行为有点像自主上下文）
  • ObjectContext 通常被移走，转而使用更简洁的 DbContext 结构（这适用于 DB first 和 Code First）
  • STEs != DB 第一代，您仍然可以在 EF 中使用 EDMX 模型，这不太可能改变。
  • 当我最初看到这篇文章时，我将 STE 误认为是仍然可用的 POCO 代理实体，并且 AFAIK 没有弃用的计划。（这些实现了对变更检测问题的类似技术解决方案，但界面更好。查看这篇文章以了解差异EF4：POCO 之间的差异，自我跟踪实体，POCO 代理

那么，这意味着什么

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

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

于 2012-12-18T06:12:43.373 回答