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

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

下一個是DTO或數據傳輸對象。這僅是一種理想的說法，“我們先把所有數據放置在某些對象中，然后你來處理它。”這與最近的討論并不相關，但確實說明了他們的想法。該話題接著簡單地提到REST。現在，我們知道Entity Framework團隊已經完全忘記自己應該建立什么。至于他們所說的“目標”。

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

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

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

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