學(xué)習(xí)ADO.NET解決方案的問題，提供完整的解決方案，他們將不會(huì)給開發(fā)者帶來任何東西。開發(fā)人員不得不在Entity Framework之上建立自己的ORM，如果他們確實(shí)要在上下文外部操作數(shù)據(jù)的話。

本文的余下部分是相當(dāng)冗長的示例，它關(guān)于如何使用新API來執(zhí)行更改跟蹤。這包括創(chuàng)建接口（例如IEntityWithChanges）、像 GetEntityState那樣使用手寫的方法進(jìn)行映射、或者在一個(gè)方法中兩者都使用，該方法接收上下文對(duì)象、實(shí)體狀態(tài)名稱、實(shí)體圖的方法與實(shí)體狀態(tài)映 射等。記住，這只適用于保存更改，你仍要先以某種方式跟蹤該更改。

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

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

Frans' LLBLGen支持類似的功能。換句話說，這是數(shù)據(jù)訪問框架做的事，而非開發(fā)人員。
談到Frans Bouma，下面是他總結(jié)的一些情況，#t#

所有那些使用數(shù)據(jù)集的開發(fā)者，如何確信EF是正確方式呢？數(shù)據(jù)集在什么時(shí)候解決過這個(gè)問題的呢，從一開始嗎？更別提是不是那些大 量競爭性的O/R映射器框架？我想核心的問題是設(shè)計(jì)框架的錯(cuò)誤，從框架開發(fā)人員的角度來看：ADO.NET解決方案在你編寫框架時(shí)，有兩種“正確點(diǎn)”——來自框架開發(fā)者的觀點(diǎn) （Point Of View，POV）和來自框架用戶的觀點(diǎn)。核心的錯(cuò)誤是假設(shè)這兩種“正確點(diǎn)”實(shí)際上是一樣的，更糟糕的是：假設(shè)框架開發(fā)者關(guān)于“正確點(diǎn)”的觀念，即是框架 用戶所想。

在之前的例子中，所有放在對(duì)象創(chuàng)建中的查詢結(jié)果都被添加到ADO.NET解決方案r中，因此我們能夠跟蹤它們的更新。如果沒有必要跟蹤對(duì)象的更新和刪除，那么最好是使用NoTracking合并項(xiàng)。例如，在一個(gè)ASP.NET Web應(yīng)用程序中，如果它要查詢一個(gè)指定的分類名稱，但卻不需要對(duì)返回的數(shù)據(jù)進(jìn)行更新，那么NoTracking就會(huì)是一個(gè)不錯(cuò)的選擇。在這種情形下，使用NoTracking的查詢會(huì)在性能方面得到改善。