ADO.NET Entity Framework 2010 不支持更改跟踪

  • Jonathan Allen
  • 王波

2008 年 11 月 27 日

话题:.NETDevOps语言 & 开发架构

社区对于 ADO.NET Entity Framework 和 LINQ to SQL 的最大不满,就是它不支持更改跟踪。但只有在你连接到上下文对象的时候,你才可以修改对象并把它们保存回数据库。就像数据库连接那样应该非常快,一旦该上下文对象超出范围,数据对象实质上就进入只读状态。重新附加它们到新上下文来回写它们的更改,这并不是一个好办法。

微软拒绝解决该难题。他们没有像大多数 ORM 库那样,在数据对象内部添加更改跟踪,改为更加关注 POCO 或者“简单初始 C# 对象”。

Entity Framework 设计博客上,微软的三位开发人员概括了一些流行的数据库访问方法。第一个是 ADO.NET DataSet,它能够回写更改的集合到数据库。他们列出了使用 ADO.NET 数据集的四个“问题”,但都意义不大。它们都集中在通过不可信边界发送更改集合,也并没有太大意义。数据集访问和 ORM 库用来净化数据,而这本该应用程序自己来处理。

下一个是 DTO 或数据传输对象。这仅是一种理想的说法,“我们先把所有数据放置在某些对象中,然后你来处理它。”这与最近的讨论并不相关,但确实说明了他们的想法。

该话题接着简单地提到 REST。现在,我们知道 Entity Framework 团队已经完全忘记自己应该建立什么。至于他们所说的“目标”,

随着对 Entity Framework 进行 N 层改进,我们想解决一些相同的问题空间,例如数据集,但要避开它一些主要问题。
理论上,我们偏向于提供用于构建的模块,它正吸引开发人员在广泛的架构之上建立解决方案。例如,我们要给 DTO 支持者提供完善的控件,同时降低在解决简单方案时所承受的痛苦。

现在问题已相当明了:Entity Framework 不想成为另一个 ORM,它想成为每个人所需的一切。就像我们一次又一次看到的那样,这种方法不会让人满意。看一下该团队的声明,

除了这两点,针对图像中做变更的问题,还有一些更有趣的通用表示法,但一般来说,它们有着相同的缺点:给它们提供解决方案并不能授权给用户控制的级别,这也是最复杂的解决方案和最成熟的模式所必须的。

接着,

对于 N 层应用程序中所描述的更改集合,Entity Framework 并无定义自己独特的表示法。换言之,它提供基本的构建模块 API,这将促进表示法的广泛使用。

由于他们不能针对操作更改集合的问题,提供完整的解决方案,他们将不会给开发者带来任何东西。开发人员不得不在 Entity Framework 之上建立自己的 ORM,如果他们确实要在上下文外部操作数据的话。

本文的余下部分是相当冗长的示例,它关于如何使用新 API 来执行更改跟踪。这包括创建接口(例如 IEntityWithChanges)、像 GetEntityState 那样使用手写的方法进行映射、或者在一个方法中两者都使用,该方法接收上下文对象、实体状态名称、实体图的方法与实体状态映射等。记住,这只适用于保存更改,你仍要先以某种方式跟踪该更改。

Ayende Rahien 解释了它是如何完成的

下面是用 NHibernate 的处理方法:

session.Merge( entityFromPresentationLayer );

Frans' LLBLGen 支持类似的功能。换句话说,这是数据访问框架做的事,而非开发人员。

谈到Frans Bouma,下面是他总结的一些情况,

所有那些使用数据集的开发者,如何确信 EF 是正确方式呢?数据集在什么时候解决过这个问题的呢,从一开始吗?更别提是不是那些大量竞争性的 O/R 映射器框架?我想核心的问题是设计框架的错误,从框架开发人员的角度来看:在你编写框架时,有两种“正确点”——来自框架开发者的观点(Point Of View,POV)和来自框架用户的观点。核心的错误是假设这两种“正确点”实际上是一样的,更糟糕的是:假设框架开发者关于“正确点”的观念,即是框架用户所想。

查看英文原文:No Change Tracking for ADO.NET Entity Framework 2010


译者简介:王波 匆匆 IT 过客,涉足于.net 编程技术,常驻于 51cto 论坛.net 版块 ,潜心研究和译书,现与友人共译《C# 3.0 揭秘》,亦分享心得于博客

.NETDevOps语言 & 开发架构