学习ADO.NET解决方案的问题，提供完整的解决方案，他们将不会给开发者带来任何东西。开发人员不得不在Entity Framework之上建立自己的ORM，如果他们确实要在上下文外部操作数据的话。

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

ADO.NET解决方案了它是如何完成的：

下面是用NHibernate的处理方法：
session.Merge( entityFromPresentationLayer );

Frans' LLBLGen支持类似的功能。换句话说，这是数据访问框架做的事，而非开发人员。
谈到Frans Bouma，下面是他总结的一些情况，#t#

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

在之前的例子中，所有放在对象创建中的查询结果都被添加到ADO.NET解决方案r中，因此我们能够跟踪它们的更新。如果没有必要跟踪对象的更新和删除，那么最好是使用NoTracking合并项。例如，在一个ASP.NET Web应用程序中，如果它要查询一个指定的分类名称，但却不需要对返回的数据进行更新，那么NoTracking就会是一个不错的选择。在这种情形下，使用NoTracking的查询会在性能方面得到改善。