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

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

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

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

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

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