ADO.NET

**ADO.NET**
操作系统	Microsoft Windows
类型	软件框架
许可协议	MS-EULA、BCL（在微软参考授权下发布）
网站	ADO.NET Overview on MSDN

ADO.NET是微软在.NET Framework中负责数据存取的类别库集，它是使用在COM时代奠基的OLE DB技术以及.NET Framework的类别库和编程语言来发展的，它可以让.NET上的任何编程语言能够连接并存取关系数据库与非数据库型数据源（例如XML，Excel或是文字档数据），或是独立出来作为处理应用程式数据的类别物件，其在.NET Framework中的地位是举足轻重，许多人将ADO.NET视为 ActiveX Data Objects (ADO) 的下一个版本，但其实它是一个全新的架构、产品与概念。

ADO.NET类封装在System.Data.dll中，并且与System.Xml.dll中的XML类集成。

历史[编辑]

发展缘起[编辑]

在1990年代初期，微软已经开发了许多的数据存取方式，像是ODBC架构、和Microsoft Access数据库交互使用的DAO物件、可以跨越网络存取数据的RDO（英语：Remote Data Objects）以及让DAO组件可以存取ODBC数据源的ODBCDirect技术等等，技术虽然多，但是却又各自为政，而且每个技术的重叠性也很高（像是ODBC有Microsoft Access的驱动程式）；RDO虽然可跨网络，但是ODBC的驱动程式中也有提供跨网络的功能（像是SQL Server和Oracle驱动程式），如此琳琅满目重叠性又高的技术群，让企业与开发人员在选择、学习与应用上产生了很多的困难。

1996年，适逢COM的出现，微软将数据存取的核心开始改写为以COM为基础的OLE DB，并且在它上面创建一个新的统一的数据存取的高层对象模型－ADO。ADO推出后顺利的取代了DAO和RDO，成为在Windows NT 4.0和Windows 2000操作系统上开发数据库应用程式的首选。它将OLE DB的物件模型进一步简化；由数据库厂商开发满足OLE DB接口的数据提供者（data provider，这个模式在此时奠基），而ADO本身则是与数据源无关（data source independent）的对象结构，让它迅速的获得了使用ASP、Visual Basic、COM的开发人员的青睐。它能够顺利取代DAO与RDO，要关键在于ADO的与数据库伺服器端/客户端的特性无关，这使得ADO通用性极好。然而ADO本身的架构仍然有缺陷（尤其是在开发网络应用程式时，最好的例子就是Recordset无法离线），这也是微软为何不在.NET Framework中继续使用ADO的主要原因。

1998年时，微软提出了一个下一代的应用程式开发框架（Application Framework）的项目^[1]，项目中包含了：

ASP+：改良与重新设计ASP技术，强化它的Web应用程式发展能力。
Storage+：发展新的数据库与面向对象之文件系统结构（用于SQL Server 8.0（即后来的SQL Server 2000）与NTFS），以及发展新一代的数据存取组件，并改良ADO本身的缺陷，让它更能够成为应用程式数据存取的核心功能。
COM+：改良COM和MTS，成为企业级应用程式开发的基础组件。

ADO+即为Storage+的一支。

ADO.NET的前身：ADO+[编辑]

1998年起，因为Web应用程式的窜起，大大改变了许多应用程式的设计方式，传统的数据库连线保存设计法无法适用于此类应用程式，这让ADO应用程式遇到了很大的瓶颈，也让微软开始思考让数据集（Resultset，在ADO中称为Recordset）能够离线化的能力，以及能在客户端创建一个小型数据库的概念^[2]^{[注 1]}，这个概念就是ADO.NET中离线型数据模型（disconnected data model）的基础，而在ADO的使用情形来看，数据库连线以及资源耗用的情形较严重（像是Server-side cursor或是Recordset.Open会保持连线状态），在ADO.NET中也改良了这些物件，构成了能够减少数据库连线和资源使用量的功能。XML的使用也是这个版本的重要发展之一。

2000年，微软的Microsoft .NET项目开始成形，许多的微软产品都冠上.NET的标签，ADO+也不例外，改名为ADO.NET^{[注 2]}，并包装到.NET Framework类别库中，成为.NET平台中唯一的数据存取组件。

架构[编辑]

ADO.NET由连线数据源（connected data source）以及离线数据模型（disconnected data model）两个部分构成^[3]，这两个部分是相辅相成的。

连线数据源[编辑]

若没办法连线到数据库，则无法被称为数据存取组件。连线数据源便是用来连接数据库（或是具有OLE DB数据源提供者）的物件类别^[4]，由下列接口构成：

IDbConnection，负责与数据库的连线管理，包含连线字符串（connection string），连线的开关，数据库交易的启始与连线错误的处理，所有的ADO.NET数据提供者都要实现此接口。
- Open()/Close()：开启与关闭数据库连线。
- BeginTransaction()：启动数据库交易，并回传一个IDbTransaction物件，以控制交易的结果。
IDbCommand，负责执行数据库指令（在大多数的案例中都是SQL指令），并传回由数据库中截取的结果集，或是执行不回传结果集的数据库指令。
- ExecuteNonQuery()：执行不回传结果集的数据库指令，像是INSERT、UPDATE与DELETE指令，返回值为该命令所影响的行数。对于其他所有类型的语句，返回值为 -1。
- ExecuteScalar()：执行指令并回传第一列第一行中的值（object类型）。当没有数据时，ExcuteScalar方法返回System.DBNull。
- ExecuteReader()：执行指令并回传IDataReader物件，以读取数据集中的数据。
- BeginExecuteNonQuery：开始执行异步查询
- EndExecuteNonQuery: 结束执行异步查询
IDataParameter，负责装载数据库指令所需要的参数数据，在使用参数化查询时会经常使用。对于不同的数据源来说，占位符不同。SQLServer数据源用@parametername格式来命名参数，OleDb以及Odbc数据源均用问号（?）来标识参数码置，而Oracle则以:parmname格式使用命名参数。
IDbTransaction，负责装载数据库交易所需的控制物件，以执行交易的认可（commit）或撤销（rollback）的工作。
- Commit()：认可数据库交易。
- Rollback()：撤销数据库交易。
IDbDataAdapter，负责将来自于IDbCommand执行获取的结果集，装载到离线型数据集（DataSet）或是离线型数据表（DataTable）中。
- Fill()：将数据填入离线型数据物件。
- Update()：将变更过的离线型数据物件中的数据写回数据库。
IDataReader，创建一个只可向前读取光标（forward-only）的数据读取器工具，以逐列读取方式存取数据，IDbDataAdapter内部也是由它来读取数据。
- Read()：第一次调用Read()方法获取第一行数据，并将游标指向下一行数据。当再次调用该方法时候，将读取下一行数据。当检测到不再有数据行时，Read()方法将返回false。
IDataRecord，在IDataReader读取数据后实际装载数据列的物件，提供方法来读取数据行中的数据，以及转换成.NET Framework原生类型的工具。
- GetOrdinal()：获取指定数据行的字段索引值。
- IsDBNull()：判断指定字段的数据是否为NULL值。

使用连线数据源需要由开发人员自我管理连线，并且直接操作数据存取的相关细节，但它的优点是速度快，而且可以自定义整个数据存取流程的逻辑。

ADO.NET数据提供者(Data Provider)[编辑]

在.NET Framework中，ADO.NET默认提供了四种数据源：

SQL Server：由System.Data.SqlClient提供原生数据源，是微软官方建议存取SQL Server时建议使用的数据提供者。以Sql为前缀的类别群
OLE DB Data Source：由System.Data.OleDb提供支持，可适用于OLE DB Provider for ODBC以外的OLE DB数据提供者。以OleDb为前缀的类别群。支持本地事务和分布式事务。对于分布式事务，默认情况下，用于 OLE DB 的 .NET Framework 数据提供程序会自动登记在事务中，并自动从 Windows 2000 组件服务获取事务详细资讯。
Oracle：由System.Data.OracleClient提供支持，但用户的电脑必须安装Oracle Client 8.1.7或更新版本才行（.NET Framework 1.1开始支持）。以Oracle为前缀的类别群。必须同时引用 System.Data和 System.Data.OracleClient。
ODBC：补OLE DB Provider for ODBC的支持，由System.Data.Odbc提供支持（.NET Framework 1.1开始支持）。以Odbc为前缀的类别群
EntityClient实体数据模型(EDM)应用程式的数据访问。使用 System.Data.EntityClient 命名空间。

其他厂商亦为不同的数据库提供数据源：

DataDirect Technologies（页面存档备份，存于互联网档案馆）发行100%列管提供源，支持主流企业数据库（Oracle, Sybase, DB2, SQL Server, Progress RDBMS）
OpenLink Software给大量的客户指定数据库发行提供源，包括到其他数据存取机构的桥接提供源，并可以在窗口下微软自己或者Mono的CLR实做下支持。
MySQL（页面存档备份，存于互联网档案馆）为本身的MySQL Database Server提供了ADO.NET的原生数据提供者。
Oracle自行开发的.NET Data Provider。

对每种Data Provider，ADO.NET要实现下述对象结构：

Connection 对象提供与数据源的连接。
Command对象使您能够访问用于返回数据、修改数据、运行存储过程以及发送或检索参数资讯的数据库命令。
DataReader 对象从数据源中提供快速的，只读的数据流。
DataAdapter 对象提供连接 DataSet 对象和数据源的桥梁。DataAdapter 使用 Command 对象在数据源中执行 SQL 命令，以便将数据加载到 DataSet 中，并使对 DataSet 中数据的更改与数据源保持一致。
Parameter 对象用于参数化查询。

例如，对于SQL Server数据源：

strSQL = "SELECT * FROM users WHERE Name = @Name and Password = @Password";
SqlParamter[] paras = new SqlParamter[]{//参数数组
     new SqlParamter("@Name",SqlDBType.Varchar,50)
     new SqlParamter("@Password",SqlDBType.Varchar,50)};
paras[0].value = userName;//绑定用户名
paras[1].value = password;//绑定用户密码

ConnectionStringBuilder：提供一种用于创建和管理由 Connection 对象使用的连接字符串的内容的简单方法。所有 ConnectionStringBuilder 对象的基类均为 DbConnectionStringBuilder 类。
CommandBuilder ：自动生成 DataAdapter 的命令属性或从存储过程中派生参数资讯，并填充 Command 对象的 Parameters 集合。所有 CommandBuilder 对象的基类均为 DbCommandBuilder 类。

离线数据模型[编辑]

离线数据模型是微软为了改良ADO在网络应用程式中的缺陷所设计的，同时它也是COM+中，IMDB技术的设计概念的实现品，但它并没有完整的IMDB功能，像是交易处理（transaction processing），但它仍不失为一个能在离线状态下处理数据的好帮手，它也可以透过连线数据源物件，支持将离线数据存回数据库的能力^[5]。离线数据模型由下列物件组成：

DataSet，离线型数据模型的核心之一，可将它当成一个离线型的数据库，它可以内含许多个DataTable，并且利用关系与限制方式来设置数据的完整性，它本身也提供了可以和XML交互作业的支持。
- ReadXml()/WriteXml()：以DataSet的结构读写XML。
- ReadXmlSchema()/WriteXmlSchema()：以DataSet的结构读写XML Schema。
- GetXml()/GetXmlSchema()：获取DataSet内容的XML或XML Schema。
- Merge()：合并两个DataSet。
- Load()：自IDataReader加载数据到DataSet。
- AcceptChanges()：将修改过的数据列的修改旗标改为Unchanged。
- GetChanges()：将修改过的数据列以DataRow数组方式传回。
- RejectChanges()：撤销所有数据的修改。
DataTable，离线型数据模型的核心之一，可将它当成一个离线型的数据表，是存储数据的收纳器。
- Copy()：将DataTable复制出一个副本，包含结构与数据。
- Merge()：将两个DataTable合并。
- Select()：以指定的特殊查询语法，传回符合条件的DataRow数组。
- Compute()：以指定的汇总语法，传回汇总的结果。
- GetErrors()：传回有错误的DataRow数组。
- HasErrors：判断DataTable中的DataRow有没有含有错误的DataRow。
DataRow，表示表格中的数据列，与数据栏组合成数据存储的单元。
- IsNull()：判断指定的字段是否为NULL值。
- ItemArray：将DataRow中的数据转换成数组。
DataColumn，表示表格中的字段。
DataView，展示数据的辅助组件，类似于数据库中的查看表，并可设置过滤条件与排序条件。
- Filter：设置DataView的过滤条件。
- Sort：设置DataView的排序条件。
- ToTable()：将应用过滤与排序后的内容转换为DataTable物件。
DataRelation，可在DataTable之间设置字段间的关系。
Constraint，设置字段的条件约束，例如ForeignKeyConstraint为外部键限制，而UniqueConstraint则确保了字段中的值都是唯一的。

DataSet和DataTable除了数据库的处理以外，也经常被用来管理应用程式中的数据，并且由于它可以存储在XML中的特性，也让它可以用来存储需要保存的应用程式资讯。DataSet中可包含DataRelation对象，用于建构表之间的约束关系。

工厂方法[编辑]

在.NET Framework 1.x的时代，ADO.NET不同的来源有不同的类别搭配（前面已述及），但是若想要在不同的数据源间搭配，那么势必要产生很多的变量来存放不同的数据物件，因此微软在.NET Framework 2.0中提供了一个System.Data.Common命名空间，其中有各种必要物件的共享方法（例如连线是DbConnection，命令是DbCommand，读取器是DbDataReader，数据适配器是DbDataAdapter等），以及DbProviderFactory物件，用来总管数据存取的物件。

DbProviderFactories则是电脑中所有提供者的总管，开发人员可用DbProviderFactories.GetFactoryClasses()获取各个提供者的Invariant Name，再于调用DbProviderFactories.GetFactory()时传入指定提供者的Invariant Name即可获取DbProviderFactory，再利用下列方法获取共享物件：

DbProviderFactory.CreateConnection()
DbProviderFactory.CreateCommand()
DbProviderFactory.CreateParameter()
DbProviderFactory.CreateDataAdapter()

// This example assumes a reference to System.Data.Common.
static DataTable GetProviderFactoryClasses()
{
    // Retrieve the installed providers and factories.
    DataTable table = DbProviderFactories.GetFactoryClasses();

    // Display each row and column value.
    foreach(DataRow row in table.Rows)
    {
        foreach(DataColumn column in table.Columns)
        {
            Console.WriteLine(row[column]);
        }
    }
    return table;
}

XML的集成[编辑]

XML在ADO.NET中扮演了相当重要的地位，DataSet和DataTable都可以转换成XML或和XML之间交换数据，在DataTable的内部数据的变更记录，可以被输出到一个XML的格式，用来识别变更的情形，这个格式称为DiffGram，而且它可以直接读入DataTable之中（使用DataTable.ReadXml（）并用XmlReadMode.DiffGram当参数）。一个典型的DiffGram如下：

<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
  <CustomerDataSet>
    <Customers diffgr:id="Customers1" msdata:rowOrder="0" diffgr:hasChanges="modified">
      <CustomerID>ALFKI</CustomerID>
      <CompanyName>New Company</CompanyName>
    </Customers>
    <Customers diffgr:id="Customers2" msdata:rowOrder="1" diffgram:hasErrors="true">
      <CustomerID>ANATR</CustomerID>
      <CompanyName>Ana Trujillo Emparedados y Helados</CompanyName>
    </Customers>
    <Customers diffgr:id="Customers3" msdata:rowOrder="2">
      <CustomerID>ANTON</CustomerID>
      <CompanyName>Antonio Moreno Taquera</CompanyName>
    </Customers>
    <Customers diffgr:id="Customers4" msdata:rowOrder="3">
      <CustomerID>AROUT</CustomerID>
      <CompanyName>Around the Horn</CompanyName>
    </Customers>
  </CustomerDataSet>
  <diffgr:before>
    <Customers diffgr:id="Customers1" msdata:rowOrder="0">
      <CustomerID>ALFKI</CustomerID>
      <CompanyName>Alfreds Futterkiste</CompanyName>
    </Customers>
  </diffgr:before>
  <diffgr:errors>
    <Customers diffgr:id="Customers2" diffgr:Error="An optimistic concurrency violation has occurred for this row."/>
  </diffgr:errors>
</diffgr:diffgram>

DataSet与DataTable也支持直接读入XML Schema创建结构的能力，以及自行依XML的内容推断（inference）其结构的能力，下列代码为由XML推断结构的程序：

DataSet dataSet = new DataSet();
dataSet.InferXmlSchema9("input_od.xml", new string[] "urn:schemas-microsoft-com:officedata");

DataSet和DataTable可以使用XmlDataDocument类别和XML DOM集成在一起，XmlDataDocument的角色就像一个桥接接口，并且作为DataSet和DataTable可使用XPath与XML DOM方式存取的方法。下列代码即为使用XmlDataDocument和数据库中数据转换为XSLT输出的示例：

// Assumes connection is a valid SqlConnection.
connection.Open();

DataSet custDS = new DataSet("CustomerDataSet");

SqlDataAdapter customerAdapter = new SqlDataAdapter(
  "SELECT * FROM Customers", connection);
customerAdapter.Fill(custDS, "Customers");

SqlDataAdapter orderAdapter = new SqlDataAdapter(
  "SELECT * FROM Orders", connection);
orderAdapter.Fill(custDS, "Orders");

connection.Close();

custDS.Relations.Add("CustOrders",
  custDS.Tables["Customers"].Columns["CustomerID"],
                     custDS.Tables["Orders"].Columns["CustomerID"]).Nested = true;

XmlDataDocument xmlDoc = new XmlDataDocument(custDS); 

XslTransform xslTran = new XslTransform();
xslTran.Load("transform.xsl");

XmlTextWriter writer = new XmlTextWriter("xslt_output.html", 
  System.Text.Encoding.UTF8);

xslTran.Transform(xmlDoc, null, writer);
writer.Close();

在.NET Framework中，DataSet被分为两类，一种是不会强制使用特别类型的DataSet，称为Untyped DataSet，使用上较方便，但没有强制的类型限制，另一种则是Typed DataSet，会强制类型，并且是由自定义的XML Schema所产生，Untyped DataSet则没有XML Schema，由创建时的结构来决定，Typed DataSet可以用Visual Studio，或者是SDK工具中的xsd.exe来产生。

xsd.exe /d /l:CS XSDSchemaFileName.xsd /eld /n:XSDSchema.Namespace

产生出来的Typed DataSet会自动将字段设置成属性，让开发人员的存取更方便（这个功能在TableAdapter相当常见）。

CustomerDataSet customers = new CustomerDataSet();
SqlDataAdapter adapter = new SqlDataAdapter(
  "SELECT * FROM dbo.Customers;",
  "Data Source=(local);Integrated " +
  "Security=SSPI;Initial Catalog=Northwind");

adapter.Fill(customers, "Customers");

foreach(CustomerDataSet.CustomersRow customerRow in customers.Customers)
  Console.WriteLine(customerRow.CustomerID);

指令产生器[编辑]

ADO.NET中有专门用来产生数据处理指令的指令产生器（Command Builder），它可以利用开发人员所指定的SELECT指令，自动产生对应的INSERT、UPDATE与DELETE指令，但一开始它并不会自动产生，而是要靠调用方法来获取：

DbCommandBuilder.GetInsertCommand()
DbCommandBuilder.GetUpdateCommand()
DbCommandBuilder.GetDeleteCommand()

最常使用到的地方是和DataAdapter并用时，但它要求传入的SELECT语句所选择的列集合中必须要有主键或者唯一键^[6]，否则无法产生，同时自动产生的指令因为判断条件很多，对性能可能会有些影响。

Visual Studio的支持[编辑]

ADO.NET和Visual Studio开发工具几乎已经是无缝的集成了，开发人员可以利用Visual Studio来创建强类型（strong-typed）的DataSet，到了Visual Studio 2005时更能够在Windows Forms应用程式中使用TableAdapter（Typed DataSet和DataAdapter集成的产物）来开发应用程式（不会再看到DataAdapter，但使用上差不多）^[7]。Visual Studio在创建Typed DataSet时有提供可视化接口的支持，以及数据库配置向导（Database Configuration Wizard）来让开发人员以简单的设置方式来创建DataSet，部分开发人员也将TableAdapter和ASP.NET应用程式的ObjectDataSource控件并用，亦得到不错的效果。

在.NET Framework 3.5中，微软特别为了DataSet和DataTable创建了LINQ Provider（称为LINQ to DataSet或LINQ to ADO.NET），让LINQ可以在DataSet或DataTable上使用，可以让原本在DataSet上的投资（代码）得以继续使用并享有LINQ的便利性。

ADO.NET和ADO的差异[编辑]

对于ADO的开发人员来说，最明显的变化在于以往ADO中的Recordset消失了，并且明确的分开为连线型的DataReader以及离线型的DataSet与DataTable，并且发展支持离线型数据源的浏览工具DataView^[8]，这样的改变，让习惯使用ADO的VB/ASP开发人员会有某种程度的不习惯，同时让ADO.NET的学习会较ADO有较些许的复杂性，因此有部分新入门或是VB 6.0/ASP开发人员会在学习.NET Framework或是使用VB.NET开发应用程式时，在.NET Framework中使用ADO来连接数据源。但在.NET Framework应用程式使用ADO的话，.NET Framework会因为要多一层ADO的COM与VB.NET使用的.NET之间的数据转换，会让应用程式性能有少部分的损耗^[9]。

下述示例，用ADO读取一个数据库中的表格，然后转为ADO.Net的数据，最后绑定到DataGridView控件中去显示：

        Dim cn As ADODB.Connection
        Dim rs As ADODB.Recordset
        cn = New ADODB.Connection
        rs = New ADODB.Recordset
        cn.Provider = "Microsoft.ACE.OLEDB.12.0;"
        cn.ConnectionString = "D:\\budget2016.accdb;"
        cn.Open()

        'check whether the serial num exists in table cutter
        Dim sSQL As String = "SELECT * FROM tPassword" 
        rs.CursorLocation = ADODB.CursorLocationEnum.adUseClient
        rs.Open(sSQL, cn, ADODB.CursorTypeEnum.adOpenKeyset, ADODB.LockTypeEnum.adLockReadOnly,_ 
                 ADODB.CommandTypeEnum.adCmdText)

        Dim da As New System.Data.OleDb.OleDbDataAdapter()
        Dim ds As New DataSet()
        da.Fill(ds, rs, "tPassword")

        'rs.Close()  'Cannot close 
        rs.ActiveConnection = Nothing
        cn.Close()
        rs = Nothing
        cn = Nothing

        DataGridView1.DataSource = (ds.Tables("tPassword"))

ADO的RecordSet，相当于在客户机或伺服器的一个逻辑上的数据表格，用户可以通过cursor来定位/读写当前行，但不能重新对这些行重新排序，也不能对客户机上的多个RecordSet数据执行跨表的连接（join）查询。ADO.Net针对上述缺点，在客户机上实现了DataTable与DataSet，这是客户机内存中的一套（多个）数据表格，可以对其执行各种单表或多表的查询、修改、删除操作，既可以使用SQL语句，也可以使用LINQ子语言。

ADO与ADO.Net的共同点，在其内部都是使用SQL语句来对后台数据库操作。

内在实现上，ADO是基于COM技术，因此变体类型（Variant）无处不在，这是一种通用、万能类型；而ADO.Net是强类型的，并很好地支持数据库元数据与XML功能。

ADO.NET的进化[编辑]

随着网络应用程式的进化，ADO.NET也随之做了许多的改变，但不变的是，ADO.NET的基础提供了强固的发展支持，这些进化的技术都是植基于ADO.NET的核心组件而来。

长久以来，程序员和数据库总是保持着一种微妙的关系，在商用应用程式中，数据库一定是不可或缺的组件，这让程序员一定要为了连接与存取数据库而去学习SQL指令，因此在资讯业中有很多人都在研究如何将程式设计模型和数据库集成在一起，物件关系对应（Object-Relational Mapping）的技术就是由此而生，像Hibernate或NHibernate都是这个技术下的产物，而微软虽然有了ADO.NET这个数据存取的利器，但却没有像NHibernate这样的物件对应工具，因此微软在.NET Framework 2.0发展时期，就提出了一个ObjectSpace的概念，ObjectSpace可以让应用程式可以用完全物件化的方法连接与存取数据库，其技术概念与NHibernate相当类似，然而ObjectSpace项目相当大，在.NET Framework 2.0完成时仍无法全部完成^[10]，因此微软将ObjectSpace纳入下一版本的.NET Framework中，并且再加上一个设计的工具（Designer），构成了现在的ADO.NET Entity Framework。

Entity Framework利用了抽象化数据结构的方式，将每个数据库物件都转换成应用程式物件（entity），而数据字段都转换为属性（property），关系则转换为结合属性（association），让数据库的E/R模型完全的转成物件模型，如此让程序员能用最熟悉的编程语言来调用存取。而在抽象化的结构之下，则是高度集成与对应结构的概念层、对应层和存储层，以及支持Entity Framework的数据提供者（provider），让数据存取的工作得以顺利与完整的进行。

以往在发展像是AJAX应用程式时，服务端总是需要设计一个HTTP接口端口（end point），通常都会使用Web Service来实现，但是随着Mashup应用程式的成长，若每次都要为一份（或一组）数据撰写Web Service或HTTP end point的话，对开发人员也是不小的负担，而且Web Service只支持XML/SOAP的数据格式，无法兼容于Mashup应用程式常用的JSON数据格式，微软也发现未来的Silverlight应用程式也是会面临到相同问题。

当时刚好微软的ADO.NET Entity Framework也正在开发中，它的EDM能力刚好可以提供给WCF数据存取的能力，因此微软特别以ADO.NET Entity Framework为基础，开发一个专门提供HTTP端点数据服务的数据供应层，即为WCF Data Services。

注释[编辑]

^ 此概念的原型为In-Memory Database，又称IMDB，可在存储器中运行的数据库，然而以当时的环境（2000年初，存储器尚未跌到目前的价格水准），以及技术不成熟的情况下，这项技术在Windows 2000 RC2时被抽离。
^ 有相同遭遇的还有ASP+（改名为ASP.NET）。

参考文献[编辑]

^ COM+, A Windows 2000 technology showcase. [2009-01-11]. （原始内容存档于2000-08-16）.
^ ADO+. [2009-01-11]. （原始内容存档于2009-12-03）.
^ ADO.NET架構. [2009-01-11]. （原始内容存档于2010-01-19）.
^ 擷取和修改ADO.NET中的資料. [2009-01-11]. （原始内容存档于2008-12-02）.
^ DataSet、DataTable及DataView（ADO.NET）. [2009-01-11]. （原始内容存档于2008-09-26）.
^ .NET Framework开发人员指南 - 使用CommandBuilder生成命令（ADO.NET）. [2009-03-18]. （原始内容存档于2009-03-19）.
^ TableAdapter. [2009-01-11]. （原始内容存档于2009-09-01）.
^ ADO.NET ─ ADO開發人員指引. [2006-04-29]. （原始内容存档于2006-01-11）.
^ Revisiting the Use of ADO in .NET Applications. [2009-01-11]. （原始内容存档于2009-01-13）.
^ A First Look at ObjectSpaces in Visual Studio 2005. [2008-08-17]. （原始内容存档于2008-09-05）.

参见[编辑]

[3] 此概念的原型为In-Memory Database，又称IMDB，可在存储器中运行的数据库，然而以当时的环境（2000年初，存储器尚未跌到目前的价格水准），以及技术不成熟的情况下，这项技术在Windows 2000 RC2时被抽离。

[4] 有相同遭遇的还有ASP+（改名为ASP.NET）。

[1] COM+, A Windows 2000 technology showcase. [2009-01-11]. （原始内容存档于2000-08-16）.

[2] ADO+. [2009-01-11]. （原始内容存档于2009-12-03）.

[5] ADO.NET架構. [2009-01-11]. （原始内容存档于2010-01-19）.

[6] 擷取和修改ADO.NET中的資料. [2009-01-11]. （原始内容存档于2008-12-02）.

[7] DataSet、DataTable及DataView（ADO.NET）. [2009-01-11]. （原始内容存档于2008-09-26）.

[8] .NET Framework开发人员指南 - 使用CommandBuilder生成命令（ADO.NET）. [2009-03-18]. （原始内容存档于2009-03-19）.

[9] TableAdapter. [2009-01-11]. （原始内容存档于2009-09-01）.

[10] ADO.NET ─ ADO開發人員指引. [2006-04-29]. （原始内容存档于2006-01-11）.

[11] Revisiting the Use of ADO in .NET Applications. [2009-01-11]. （原始内容存档于2009-01-13）.

[12] A First Look at ObjectSpaces in Visual Studio 2005. [2008-08-17]. （原始内容存档于2008-09-05）.

[1]

[2]

[注 1]

[注 2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]