社區(qū)對于ADO.NET Entity Framework和LINQ to SQL的***不滿，就是它不支持更改跟蹤。但只有在你連接到上下文對象的時候，你才可以修改對象并把它們保存回數(shù)據(jù)庫。就像數(shù)據(jù)庫連接那樣應(yīng)該非?？?，一旦該上下文對象超出范圍，數(shù)據(jù)對象實質(zhì)上就進入只讀狀態(tài)。重新附加它們到新上下文來回寫它們的更改，這并不是一個好辦法。

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

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

下一個是DTO或數(shù)據(jù)傳輸對象。這僅是一種理想的說法，“我們先把所有數(shù)據(jù)放置在某些對象中，然后你來處理它?！边@與最近的討論并不相關(guān)，但確實說明了他們的想法。該話題接著簡單地提到REST?，F(xiàn)在，我們知道ADO.NET Entity Framework團隊已經(jīng)完全忘記自己應(yīng)該建立什么。至于他們所說的“目標(biāo)”，

隨著對Entity Framework進行N層改進，我們想解決一些相同的問題空間，例如數(shù)據(jù)集，但要避開它一些主要問題。 理論上，我們偏向于提供用于構(gòu)建的模塊，它正吸引開發(fā)人員在廣泛的架構(gòu)之上建立解決方案。例如，我們要給DTO支持者提供完善的控件，同時降低在解決簡單方案時所承受的痛苦。

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