社區對于ADO.NET應用程序和LINQ to SQL的***不滿，就是它不支持更改跟蹤。但只有在你連接到上下文對象的時候，你才可以修改對象并把它們保存回數據庫。就像數據庫連接那樣應該非常快，一 旦該上下文對象超出范圍，數據對象實質上就進入只讀狀態。重新附加它們到新上下文來回寫它們的更改，這并不是一個好辦法。

微軟拒絕解決該難題。他們沒有像大多數ORM庫那樣，在數據對象內部添加更改跟蹤，改為更加關注POCO或者“簡單初始C#對象”。

在Entity Framework設計博客上， 微軟的三位開發人員概括了一些流行的數據庫訪問方法。***個是ADO.NET應用程序 DataSet，它能夠回寫更改的集合到數據庫。他們列出了使用ADO.NET應用程序數據集的四個“問題”，但都意義不大。它們都集中在通過不可信邊界發送更改 集合，也并沒有太大意義。數據集訪問和ORM庫用來凈化數據，而這本該應用程序自己來處理。

下一個是DTO或數據傳輸對象。這僅是一種理想的說法，“我們先把所有數據放置在某些對象中，然后你來處理它。”這與最近的討論并不相關，但確實說明了他們的想法。

該話題接著簡單地提到REST。現在，我們知道Entity Framework團隊已經完全忘記自己應該建立什么。至于他們所說的“目標”，隨著對Entity Framework進行N層改進，我們想解決一些相同的問題空間，例如數據集，ADO.NET應用程序但要避開它一些主要問題。#t#

 理論上，我們偏向于提供用于構建的模塊，它正吸引開發人員在廣泛的架構之上建立解決方案。例如，我們要給DTO支持者提供完善的控件，同時降低在解決簡單方案時所承受的痛苦。

現在問題已相當明了：Entity Framework不想成為另一個ORM，ADO.NET想成為每個人所需的一切。就像我們一次又一次看到的那樣，這種方法不會讓人滿意。看一下該團隊的聲明，除了這兩點，針對圖像中做變更的問題，還有一些更有趣的通用表示法，但一般來說，它們有著相同的缺點：給它們提供解決方案并不能授權給用戶控制的級別，這也是最復雜的解決方案和最成熟的模式所必須的。
接著，

ADO.NET應用程序中所描述的更改集合，Entity Framework并無定義自己獨特的表示法。換言之，它提供基本的構建模塊API，這將促進表示法的廣泛使用。