本文主要講述ADO.NET數(shù)據(jù)集，怎樣創(chuàng)建ADO.NET數(shù)據(jù)集。這些內(nèi)容都是一些門戶網(wǎng)站和技術(shù)論壇找到的，中間可能有不少錯(cuò)誤是我沒有挑出的，歡迎大家指正。重新附加它們到新上下文來回寫它們的更改，這并不是一個(gè)好辦法。

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

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

隨著對(duì)Entity Framework進(jìn)行N層改進(jìn)，我們想解決一些相同的問題空間，例如數(shù)據(jù)集，但要避開它一些主要問題。
理論上，我們偏向于提供用于構(gòu)建的模塊，它正吸引開發(fā)人員在廣泛的架構(gòu)之上建立解決方案。例如，ADO.NET數(shù)據(jù)集我們要給DTO支持者提供完善的控件，同時(shí)降低在解決簡單方案時(shí)所承受的痛苦。
現(xiàn)在問題已相當(dāng)明了：Entity Framework不想成為另一個(gè)ORM，它想成為每個(gè)人所需的一切。就像我們一次又一次看到的那樣，這種方法不會(huì)讓人滿意。看一下該團(tuán)隊(duì)的聲明，

除了這兩點(diǎn)，針對(duì)圖像中做變更的問題，還有一些更有趣的通用表示法，但一般來說，ADO.NET數(shù)據(jù)集有著相同的缺點(diǎn)：給它們提供解決方案并不能授權(quán)給用戶控制的級(jí)別，這也是最復(fù)雜的解決方案和最成熟的模式所必須的。 #t#

對(duì)于N層應(yīng)用程序中所描述的更改集合，Entity Framework并無定義自己獨(dú)特的表示法。換言之，它提供基本的構(gòu)建模塊API，這將促進(jìn)表示法的廣泛使用。
由于他們不能針對(duì)操作更改集合的問題，提供完整的解決方案，他們將不會(huì)給開發(fā)者帶來任何東西。開發(fā)人員不得不在Entity Framework之上建立自己的ORM，如果他們確實(shí)要在上下文外部操作數(shù)據(jù)的話。

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