Bob Beauchemin
DevelopMentor

適用于：
Microsoft ADO.NET 2.0
Microsoft Visual Studio 2005
C# 編程語言

摘要：了解在 ADO.NET 中對于從您的數據源訪問元數據的增強支持。

下載相關的 SchemasSample.exe 示例代碼。

本頁內容

	深入了解新的公共元數據 API
	究竟誰需要元數據？
	我能得到什么樣的元數據？
	Restrictions
	DataSourceInformation
	自定義并擴展元數據
	用戶自定義
	小結：元數據支持的最終部分

深入了解新的公共元數據 API

在我的前一篇文章，我指出 Visual Studio 2005 服務器資源管理器現在使用一個包含了 .NET 數據提供程序（而不是 OLE DB 提供程序）列表的對話框來提示連接信息。當您確定一個連接字符串并添加數據連接時，每個數據連接也顯示一個關于通過連接直接可見的數據庫對象（如表、視圖和存儲過程）的信息的樹形結構。但這些信息來自哪里呢？難道是 Visual Studio 僅為某些數據提供程序硬編碼來生成這個信息，而假如我編寫我自己的數據提供程序或者從第三方購買一個的時候，就留給我一個空節點？不，在 Visual Studio 2005 中并不是這樣。由于 ADO.NET 2.0 中的新架構 API，所有這些有用的信息都將提供給您。我不知道這是否是 Visual Studio 做到它的方法，但是這里就是使用新的 API 來獲得一個數據庫中的表的列表的代碼。

// uses a ADO.NET 2.0 named connection string in config file
// uses ADO.NET 2.0 ProviderFactory and base classes
// see previous article 
public static void GetListOfTables(string connectstring_name)
{ConnectionStringSettings s =  ConfigurationSettings.ConnectionStrings[connectstring_name];DbProviderFactory f = DbProviderFactories.GetFactory(s.ProviderName);using (DbConnection conn = f.CreateConnection()){conn.ConnectionString = s.ConnectionString;conn.Open();DataTable t = conn.GetSchema("Tables");t.WriteXml("tables.xml");}
} 

返回頁首

究竟誰需要元數據？

元數據是每個數據訪問 API 的一部分。盡管元數據的主要使用者是像 Visual Studio 這樣的工具或者像 DeKlarit 這樣的代碼生成器，但是它們并不是惟一的使用者。應用程序包設計師可能允許最終用戶通過向現有的表添加新表或新列來自定義一個應用程序。當最終用戶如此改變了數據庫架構時，一個通用查詢和修改工具可以在維護、備份和其他應用程序函數中使用元數據來包含用戶的新表，就像它們是應用程序附帶的內置表一樣。程序員可以使用元數據來編寫他們自己的派生自 System.Data.Common.DbCommandBuilder的自定義類，并為使用 DataSet 創建插入、更新和刪除命令。多數據庫應用程序（即設計為在用戶選擇的數據庫上運行的應用程序）的構建者可以盡可能多地使用元數據來維護公共代碼庫，在需要時優化數據訪問代碼。

通過一般元數據 API 來公開元數據要比讓每個使用者使用特定于數據庫的 API 要好。這樣，工具編寫人員可以維護一個可管理性更好的代碼庫。這樣的 API 還必須是非常靈活的，因為在編寫一般 API 來公開元數據時有四個障礙需要考慮。

1.	元數據集合和信息在數據庫間是有差別的。例如，SQL Server 用戶可能想要公開一個鏈接服務器的集合，但是 Oracle 用戶可能對關于 Oracle 序列的信息感興趣。
2.	不僅在不同的數據庫產品中，而且即使在相同數據庫的不同版本中，存儲公共數據庫元數據的基礎系統表都是不同的。例如，SQL Server 2005 使用在一個“sys”架構下的新表（例如，sys.tables）公開它的元數據，而 SQL Server 以前的版本使用元數據表（如 sysobjects￡?來存儲相同的數據。
3.	不同的程序可能有不同的元數據視圖。以一個例子來說，許多程序員抱怨 Oracle 數據庫中表的列表太長，因為大多數元數據 API 將“system”表與用戶表混在一起。他們想要一個僅由他們定義的表組成的短列表。
4.	是否根本不支持元數據，要提供多少元數據，應該完全取決于提供程序的編寫者。

大部分數據庫 API 提供一個標準的元數據集，它是所有提供程序必須支持的，并且允許提供程序編寫者添加新的元數據表。這與使用 ANSI SQL 標準采用的方法是一致的。解決這一問題的標準的一部分是 Schema Schemata（INFORMATION_SCHEMA 和 DEFINITION_SCHEMA）的第 11 部分。ANSI SQL INFORMATION_SCHEMA 定義了由一個兼容的數據庫支持的標準的元數據視圖集。但即便是這個規范也需要有一個方法來解決上面這些問題。它聲明：

“實施者可以自由添加額外的表到 INFORMATION_SCHEMA 或添加額外的列到預定義的INFORMATION_SCHEMA 表。”

OLE DB 作為一個與 ANSI SQL 標準概念一致的數據訪問 API 示例，定義了一系列的名為“架構行集合”的元數據。它從一個大致遵循 INFORMATION_SCHEMA 的預定義集開始，并添加 OLE DB 特定的列到每個行中。ADO.NET 2.0 提供了一個甚至更強大更靈活的機制來公開元數據。

返回頁首

我能得到什么樣的元數據？

ADO.NET 2.0 允許提供程序編寫者公開 5 種不同類型的元數據。這些主要的元數據 — “元數據集合”或“類別” — 在 System.Data.Common.DbMetaDataCollectionNames 類中被枚舉出來。

?	MetaDataCollections — 可用元數據集合的列表。
?	Restrictions — 對于每個元數據集合，存在一批可以用于限制被請求的架構信息范圍的限定符。
?	DataSourceInformation — 關于數據提供程序引用的數據庫實例的信息。
?	DataTypes — 一組關于數據庫支持的每個數據類型的信息。
?	ReservedWords — 適用于該種數據庫查詢語言的保留字。通常“查詢語言”等同于一種 SQL 的方言。

MetaDataCollections 是 INFORMATION_SCHEMA 集合的名稱，如“表”、“列”或“主鍵”。但是，如果使用 DbConnection.GetSchema，這些元數據類別也被認為是元數據。這意味著在代碼方面來說是這樣，這些集合可以像普通的元數據一樣被獲得。

// gets information about database Views
Table t1 = conn.GetSchema("Views");
// gets information about collections exposed by this provider
// this includes the five "meta-collections" described above
Table t2 = conn.GetSchema(DbMetaDataCollectionNames.MetaDataCollections);
// gets information about the Restrictions meta-collection
Table t3 = conn.GetSchema(DbMetaDataCollectionNames.Restrictions);
// No argument overload is same as asking for MetaDataCollections
Table t4 = conn.GetSchema();

5 個元數據集合中的 2 個值得進一步解釋。

返回頁首

Restrictions

Restrictions 可以用來限制返回元數據的數量。如果您熟悉 OLE DB 或 ADO，那么術語“restriction”意味著在那些 API 中同樣的內容。作為示例，讓我們使用 MetaDataCollection“列”，它是表中的列名稱的集合。這個集合可以用于獲取所有表中的所有列。但是，此被請求的列集合會被數據庫名稱、所有者/架構或者表限制。每個元數據集合可以有不同數量的可能限制，并且每個限制會有一個默認值。在我們下面的示例中，這里是一個對列元數據的限制的 XML 表示：

清單 1. 列集合上的 Restrictions（XML 格式）

<Restrictions> <CollectionName>Columns</CollectionName> <RestrictionName>Catalog</RestrictionName> <RestrictionDefault>table_catalog</RestrictionDefault> <RestrictionNumber>1</RestrictionNumber> </Restrictions> <Restrictions> <CollectionName>Columns</CollectionName> <RestrictionName>Owner</RestrictionName> <RestrictionDefault>table_schema</RestrictionDefault> <RestrictionNumber>2</RestrictionNumber> </Restrictions> <Restrictions> <CollectionName>Columns</CollectionName> <RestrictionName>Table</RestrictionName> <RestrictionDefault>table_name</RestrictionDefault> <RestrictionNumber>3</RestrictionNumber> </Restrictions> <Restrictions> <CollectionName>Columns</CollectionName> <RestrictionName>Column</RestrictionName> <RestrictionDefault>column_name</RestrictionDefault> <RestrictionNumber>4</RestrictionNumber> 
</Restrictions> 

Restrictions 是使用一個重載的 DbConnection.GetSchema 指定的。這些限制被指定為一個數組。您可以將一個數組指定為和整個限制集合或者一個子集數組一樣大，因為“RestrictionNumbers”通常從最少限制向最多限制發展。對您想要省略的限制值使用空值（不是數據庫 NULL，而是 .NET NULL，或者在 Visual Basic .NET 中的 Nothing）。例如：

// restriction string array
string[] res = new string[4];// all columns, all tables owned by dbo
res[1] = "dbo";
DataTable t1 = conn.GetSchema("Columns", res);// clear collection
for (int i = 0; i < 4; i++) res[i] = null;
// all columns, all tables named "authors", any owner/schema
res[2] = "authors";
DataTable t2 = conn.GetSchema("Columns", res);// clear collection
for (int i = 0; i < 4; i++) res[i] = null;
// columns named au_lname 
// all tables named "authors", any owner/schema
res[2] = "authors";  res[3] = "au_lname";
DataTable t3 = conn.GetSchema("Columns", res);// clear collection
for (int i = 0; i < 4; i++) res[i] = null;
// columns named au_lname 
// any tables, any owner/schema
res[3] = "name";
DataTable t4 = conn.GetSchema("Columns", res);

您無需指定整個限制數組。在上面的情況中，這里您只想看到“dbo”擁有的表中的列，您可以指定一個只帶有兩個而不是全部四個成員的數組。也請注意，將一個空字符串指定為一個限制與指定一個 null（在 Visual Basic .NET 中為 Nothing）值是不同的。您不必記住這些限制，您始終可以查詢它們，就像任何其他集合一樣。“Restrictions”集合本身不允許限制，但是因為信息被提取到 DataTable 中，所以您可以使用一個 DataView 來提供相似的功能，如下所示。

DataTable tv = conn.GetSchema(DbMetaDataCollectionNames.Restrictions);
DataView v = tv.DefaultView;
// show restrictions on the "Columns" collection, sorted by number
v.RowFilter = "CollectionName = 'Columns'";
v.Sort = "RestrictionNumber";
for (int i = 0; i < tv.Count; i++)Console.WriteLine("{0} (default){1}",tv.Rows[i]["RestrictionName"], tv.Rows[i]["RestrictionDefault"]);

返回頁首

DataSourceInformation

DataSourceInformation 集合為查詢生成器提供關于當前數據庫（數據源）實例的信息。雖然這個集合可包含提供程序需要的任何內容，但在 Microsoft 提供程序 (SqlClient、OracleClient、OleDb、Odbc) 中，這個集合包含相似的信息。這里是您默認獲得的信息。

表 1. 在 Microsoft 提供程序中的 DataSourceInformation
值	格式/意義
CompositeIdentifierSeparatorPattern	多部分名稱的分隔符（如 pubs.dbo.authors 中的點）
DataSourceProductName	數據庫名稱
DataSourceProductVersion	數據庫版本。請注意這是當前通過 DbConnection 訪問的數據庫實例的版本。
DataSourceProductVersionNormalized	?
GroupByBehavior	枚舉，System.Data.Common.GroupByBehavior
IdentifierPattern	正則表達式字符串
IdentifierCase	枚舉，System.Data.Common.IdentifierCase
OrderByColumnsInSelect	布爾值，默認情況下您應該在一個 SELECT 語句中 ORDER BY 這些列
ParameterMarkerFormat	說明參數標記是否以一個特殊的字符開始（如 T-SQL 中的 @）
ParameterMarkerPattern	用于創建參數的正則表達式字符串
ParameterNameMaxLength	參數的最大長度
ParameterNamePattern	用于創建參數的正則表達式字符串
QuotedIdentifierPattern	用于引用標識符的正則表達式字符串
QuotedIdentifierCase	枚舉，System.Data.Common.IdentifierCase
StatementSeparatorPattern	正則表達式字符串
StringLiteralPattern	正則表達式字符串
SupportedJoinOperators	枚舉，System.Data.Common.SupportedJoinOperators

對特定的數據庫方言來說有太多的信息來產生 SQL 了，您不這樣認為么？還有一條信息我想要說一下，那就是提供程序是否在參數化查詢中使用命名參數或者位置參數。在我關于編寫獨立于提供程序的代碼的上一篇文章中，我將命名和位置參數作為編寫參數化命令的兩種方法來討論。

返回頁首

自定義并擴展元數據

既然我們已經看到了提供的基礎元數據并且可以圍繞 DbConnection.GetSchema() 找到我們的方法，讓我們討論提供程序編寫者使用簡單的聲明性格式自定義元數據的方法，以及程序員如何能夠掛鉤到那種格式中。這個討論與文章開始的元數據復雜性相關：如何提供獨立于數據庫版本的元數據以及如何處理不同使用者可能需要相同元數據的不同視圖的事實。

首先，讓我們指出元數據支持完全是可選的。提供程序不必支持 DbConnection.GetSchema，這種方法會引發 NotSupportedException。此外，如果提供程序編寫者選擇支持 DbConnection.GetSchema，只有 MetaDataCollections 類別是必需的。提供程序可以選擇不提供任何或所有其他 4 個類別的信息。

其次，每個提供程序可以公開相同元數據集合的不同信息。例如，Tables 集合的結構完全取決于提供程序編寫者。舉個例子，SqlClient 提供程序在 Tables 集合中公開了 4 個信息項：table_catalog、table_schema、table_name 和 table_type。OracleClient 提供程序僅公開了 3 個信息項（OWNER、TABLE_NAME 和 TYPE），因為 Oracle 數據庫不包含多種目錄。對每個提供程序來說限制和限制項的數量可以是不同的。再次以表的情況為例，SqlClient 提供程序支持 4 個限制，而 OracleClient 提供程序只支持 2 個。限制也不必按照任何指定的順序發生。所以與在 OLE DB 和 ODBC API 中不同，這里沒有委托管理的元數據結構、大量元數據或者元數據順序。提供程序可以自由公開任何相關的元數據。但是，如果一個特定的應用程序（如 Visual Studio）要求在一個應用程序里使用的所有 .NET 數據提供程序中元數據是一致的，它也能夠通過覆蓋提供程序的標準行為來獲得這個行為。我們將在后面的用戶自定義小節進一步討論這個問題。

提供程序編寫者可以將元數據邏輯直接硬編碼到他們的提供程序中，每個提供程序編寫者為了獲得相似的元數據可以使用不同的內部算法。例如，在實現 OLE DB 的 ISchemaRowset 方法時，這就是過去完成它的方法。但是，在 ADO.NET 2.0 中，在 System.Data.ProviderBase 命名空間中有一些基類是提供程序編寫者可用的。4 個可用的 Microsoft 提供程序使用這些基類，因此它們都以相似的方法實現架構。我將用這個實現進行講解，希望大多數編寫提供程序的程序員喜歡 DataDirect 技術，而其他提供程序編寫者也使用它。

公開元數據的基類是 DbMetaDataFactory。實現它的一個子類的提供程序使用一個 XML 文件來定義其元數據提取行為。這些文件是在 System.Data.dll 和 System.Data.OracleClient.dll 中嵌入的資源，您可以通過從命令行運行 ILDASM.exe 來查看原始的 XML 文件。

>ildasm.exe System.Data.dll /out:dummy.il

查看從 ILDASM 生成的 XML 資源文件，如同剝開了洋蔥的另一層。這個文件枚舉了被支持的集合以及包含在每個元數據集合（通過架構）中的信息，并且看起來是使用 DataSet.WriteXml(XmlWriteMode.WriteSchema) 重載的 DataSet.WriteXml 方法的輸出。最有趣的部分是在除了 DataSourceInformation 和 MetaDataCollections 元素中的 PopulationMechanism/PopulationString 子元素以外的所有元數據集合中的 MinimumVersion/MaximumVersion 元素。

使用 MinimumVersion/MaximumVersion 允許提供程序編寫者指定對于不同版本的數據庫要執行哪些元數據查詢。通過使用單個 MetaDataCollection 的多個元素，您可以使 GetSchema 對不同版本的數據庫表現不同。舉一個明顯的例子，您可以使用與以前版本的 SQL Server 不同的 SQL Server 2005 各版本。這里是一個使用來自 SQL Server 元數據資源 (System.Data.SqlClient.SqlMetaData) 的 MinimumVersion 的例子：

清單 2. 數據類型集合中的數據類型 XML 的元數據項

<DataTypes> <TypeName>xml</TypeName> <ProviderDbType>25</ProviderDbType> <ColumnSize>2147483647</ColumnSize><DataType>System.String</DataType> <IsAutoIncrementable>false</IsAutoIncrementable><IsCaseSensitive>false</IsCaseSensitive> <IsFixedLength>false</IsFixedLength> <IsFixedPrecisionScale>false</IsFixedPrecisionScale> <IsLong>true</IsLong> <IsNullable>true</IsNullable> <IsSearchable>true</IsSearchable> <IsSearchableWithLike>false</IsSearchableWithLike> <MinimumVersion>09.00.000.0</MinimumVersion> <IsLiteralSupported>false</IsLiteralSupported> 
</DataTypes> 

這定義了關于 SQL Server 數據類型 XML 的信息。MinimumVersion 指示出，這個數據類型只在使用 SQL Server 2005 時可用。如果您要求 SqlConnection.GetSchema 提供數據庫支持的數據類型列表，只有 SQL Server 2005 的各版本數據庫（SQL Server 2005 是版本 9，當前的beta 2 版是 09.00.852.2）會報告它們支持 XML 數據類型。

對于通常被 INFORMATION_SCHEMA（如表、視圖或存儲過程）公開的集合，PopulationMechanism 和 PopulationString 是工作開始的地方。在這個實現中使用了三個 PopulationMechanisms：DataTable、SQLCommand 和 PrepareCollection。DataTable 用于填充元數據集合。使用 DataTable 意味著用于填充集合的信息是在 XML 資源文件本身當中。在每種情況下，PopulationString 是當 XML 資源文件加載到一個 .NET DataSet 時，生成的 DataTable 的名稱。SQLCommand 意味著提供程序將使用一個 DbCommand 實例來發出對數據庫的命令。如果您查看由 SQLCommand 產生的集合的一個 PopulationString：

清單 3. SQL Server 中的數據庫（目錄）項 — MetaDataCollection

<MetaDataCollections> <CollectionName>Databases</CollectionName> <NumberOfRestrictions>1</NumberOfRestrictions> <NumberOfIdentifierParts>1</NumberOfIdentifierParts> <PopulationMechanism>SQLCommand</PopulationMechanism> <PopulationString>select name as database_name, dbid, crdate as create_date from master..sysdatabases where name = {0}</PopulationString> 
</MetaDataCollections> 

當限制在 DbConnection.GetSchema 中使用時，很容易就能夠推斷出字符串替換將被應用到“基查詢”中。如果沒有限制被指定，那么實際上該謂詞將被剝離出查詢。

當 PopulationMechanism 的值為 PrepareCommand 時，提供程序編寫者可以使用自定義機制。有一個 DbMetaDataFactory 的 PrepareCommand 方法，如果它被提供程序編寫者覆蓋，就可以被編碼來使用提供程序選擇的任何自定義語義。這一機制被用在 SqlClient 中來生成 DataTypes 元數據集合。PrepareCommand 的 SqlMetaDataFactory 子類實現首先從 DataTable 中讀取由 SQL Server 支持的內置數據類型，如同用其他元數據集合一樣；然后，如果數據庫是 SQL Server 2005 的話，使用自定義邏輯來將用戶定義的類型添加到集合中。（注：SQL Server 2005 可以將 .NET 類作為用戶定義的類型公開。更多信息請參閱 A First Look at SQL Server 2005 for Developers 的第 5 章。）

返回頁首

用戶自定義

除了提供程序自定義機制外，也有允許程序員在每個應用程序基礎上自定義架構信息的掛鉤！在加載嵌入資源之前，DbConnectionFactory CreateMetaDataFactory 將參考應用程序配置文件。每個提供程序都可以用任何它選擇的方法實現 CreateMetaDataFactory 來為其 DbMetaDataFactory 獲取 XML 流，但是那 4 個 Microsoft 提供程序遵循一個公共模式。每個 Microsoft 提供程序將查找一個按提供程序本身命名的應用程序配置設置（如 system.data.sqlclient）。在這個設置元素中您可以添加或刪除名值對。DbMetaDataFactory 查找一個名稱“MetaDataXml”。與特殊名稱對應的值是一個文件的名稱。這是一個簡單的文件名 — 這個文件必須存在于 .NET 安裝位置的 CONFIG 子目錄中。這是 machine.config 和安全配置設置所在的目錄。這個文件必須包含整個的架構配置信息集，而不僅僅是那些更改。

出于多個原因，對于支持此機制的提供程序，您可以使用這個機制。例如，您可以更改 OracleClient 提供程序中的架構查詢來使用“USER”目錄視圖而不是“ALL”目錄視圖。因為“USER”視圖不包含關于內部數據庫表的信息，例如，表列表將會短很多并且更易于使用。另一個示例可能包括為所有的 .NET 數據提供程序編碼輸出元數據 XML 文件，這提供給您一致的標準元數據集，該元數據集可能正好符合 SQL-99 INFORMATION_SCHEMA 視圖。這可能恰恰適合您的應用程序。

一個更具體的例子是，如果我想要公開 SQL Server 2005 中關于 SQL Server Service Broker 的元數據集合的信息。這些集合可以包括 QUEUE、SERVICE、CONTRACT 和消息類型。我會從嵌入的 XML 資源文件開始并用我的新集合上的信息修飾它。如果這個文件的名稱是 SQLBrokerAware.xml，我會安裝這個文件，我的應用程序配置文件將為如下所示：

<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.data.sqlclient> <settings> <add name="MetaDataXml" value="SQLBrokerAware.xml"></add> </settings> </system.data.sqlclient> </configuration> 

這就是所有的步驟。使用這個設置，我可以編寫代碼 — 在其中 Service Broker 元數據是可用于客戶端的內置元數據的組成部分。對所有隊列來說，代碼可能如下所示：

using (SqlConnection conn = new SqlConnection(connstring))
{conn.Open();// this includes Service Broker metadata collectionsTable t = conn.GetSchema(DbMetaDataCollectionNames.MetaDataCollections);// get all the queues in my databaseTable queues = conn.GetSchema("Queues");
}

真是非常酷！本文包含一個添加 Service Broker 元數據的代碼示例。盡管這是一個非常強大的功能，它還是有可能被濫用的。請記住您需要將元數據 XML 文件分發到每個使用它的應用程序，并說服系統管理員為您將其安裝在 CONFIG 目錄中。而且您需要用發布的提供程序的每個新版本來維護它。因為使用一般元數據 API 的理由之一是可擁有跨數據庫和應用程序的一致元數據，所以這個功能不應被無故使用。還需注意此時您不能提供 PrepareCommand 的自定義實現。

關于自定義的最后要注意的，您可能已經猜到了，自定義和資源對于 OLE DB 和 ODBC 的橋提供程序的使用是不同的。當您使用這些提供程序時，默認的 Odbc 或 OleDb XML 資源文件被使用，然后您不僅可以自定義主要的 Odbc 或 OleDb 架構行為，而且可以在每個提供程序基礎上自定義行為。如果您想要指定自己的提供程序或者驅動程序，在添加/刪除設置子元素中使用的名稱屬性不能是 MetaDataXml，而應該是 [providershortname]:MetaDataXml。如果您想讓您的文件成為 OleDb 或 Odbc 數據提供程序的默認文件，您甚至可以指定 defaultMetaDataXml 的名稱。

返回頁首

小結：元數據支持的最終部分

在結束前，我只想說說其他兩個不是通過 DbConnection.GetSchema 公開的元數據擴展。 DbCommandBuilder 包含兩個屬性，QuoteIdentifier 和 UnquoteIdentifier，它們允許您在由 CommandBuilder 生成的命令中自定義標識符。舉個例子，根據您的會話設置，在 SQL Server 中您可以使用雙引號 (") 或括號（'[' 和 ']'）來引用標識符。最后，在 System.Data.Sql 命名空間中的 SqlMetaData 類被用于公開 SQL Server DataReader 中的元數據并允許您在 SqlCommand 使用的 Parameters 中設置這個元數據。雖然不是任何地方在細節上都非常接近，但是這個元數據在概念上與在 DataTypes 元數據集合中公開的元數據相似。SqlMetaData 對 SqlClient 數據提供程序和 SQL Server 2005 包括的 in-database SqlServer 數據提供程序都是適用的。SqlMetaData 增大了當前通過 SqlDataReader.GetSchemaTable() 方法公開的行集合元數據。

此時您很可能同意 ADO.NET 2.0 元數據基礎結構是您所見過的最強大、靈活和可自定義的結構。它將 ADO.NET 發展成為一個完全面向對象的數據庫 API。工具供應商、提供程序編寫者和 Visual Studio 數據工具用戶將會高興地在街上跳舞 — 我們那里見。

Bob Beauchemin，DevelopMentor 的講師、課程作者和數據庫課程聯絡員。作為以數據為中心的分布式系統的架構師、程序員和管理員，他有超過 25 年的經驗。他一直為 Microsoft Systems Journal 和 SQL Server Magazine 等雜志撰寫 ADO.NET、OLE DB 和 SQL Server 方面的文章，并且是 A First Look at SQL Server 2005 for Developers 和 Essential ADO.NET 的作者。

轉到原英文頁面

總結

以上是生活随笔為你收集整理的ADO.NET 2.0 中的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。