細說ADO.NET命令

2019-11-17 04:53:12

字體：大中小

來源：轉載

供稿：網友

　　在ADO中，有三種可能方式用于更新數據源。一個是通過直接SQL語句，如INSERT, DELETE 或 UPDATE，或稍復雜、較成熟的存儲過程。另一個是通過批更新，你一次可以向服務器遞交某個表的新映射。第三個方法是使用服務器指針直接對字段更新。　　ADO .NET完全支持前兩種技術，這涉及到不是的對象和方法。至于服務器指針，需要做進一步的討論和確認，但到目前為止，在ADO .NET中它們只得到有限的支持。　　下面開始分析在ADO .NET中更新數據源的方法和技術。本月，我將重點放在直接SQL命令和存儲過程上。在以后的專欄中，我將同時具體介紹批更新和服務器指針。　　OLE DB 和"治理"提供者　　ADO .NET并不直接支持OLE DB提供者，但這并不是說你不能從ADO .NET中訪問OLE DB提供者。對此，我只是要表明一個非凡的治理提供者總是對訪問任何現有的有效OLE DB提供的調用進行預處理。出于這個原因，你的ADO .NET永遠不會直接作為一個OLE DB客戶。　　治理提供者是在.NET中工作的一種模塊，它的工作方式與OLE DB在Win32? 和 COM環境中的工作方式相同。從任何角度來說，治理提供者是OLE DB的.NET對應物。它們是簡化了的組件，并不象OLE DB那樣遵循復雜的通用的規范（如通用數據訪問）。　　更重要的是，治理提供者完全能在.NET的通用語言運行時（Common Language Runtime ，CLR）環境中工作。相反，OLE DB提供者是一個老COM對象，在.NET環境中，它只能運行在非治理窗口中。　　為了訪問ADO.NET中的數據，你應當遵循典型ADO會話中的同樣步驟。首先，創建鏈接，通過連接字符串指定參數。接著，實例化命令對象，設置正確的命令字和行為，然后執行。最后，根據命令的期望輸出，或者你操縱結果，或者關閉鏈接，將其余工作留給應用程序。　　注重，在ADO中可以減少一些步驟，如直接調用Connection對象的Execute方法。這種做法在ADO .NET中是不答應的，因為并不是所有類型的Connection對象具有Execute方法。　　不同類型的鏈接對象？這又意味著什么呢？　　ADO .NET要求你在鏈接時事先知道并指定將鏈接到的（治理）數據提供者的類型。在ADO中，你擁有Connection對象，這就足夠了，而不必考慮獲得和設置數據的物理通道。不論是使用OLE DB ，還是歸結為ODBC，通過供ODBC使用的通用OLE DB提供者，ADO 總是要求使用同種類型的Connection對象。在ADO .NET中情況就不是這樣了。　　到目前為止，有兩種類型的治理提供者，一個專門用于SQL Server 7.0 和 2000，另一個用于訪問任何OLE DB提供者。通過治理提供者，輕易辨別出這種設計方式與在ADO中答應ODBC數據源訪問OLE DB的方式是相同的。　　用于訪問ODBC數據源的第三方治理提供者現在處于測試階段。事實上，用于OLE DB的治理提供者不支持ADO中用于同ODBC驅動對話的MSDASQL OLE DB提供者。
SQL Server是在System.Data.SqlClient名稱空間中定義它的類的。OLE DB 治理提供者大部分定義在System.Data.OleDb名稱空間中。　　在ADO .NET中，不存在通用而又有用的鏈接類。存在一個DBConnection類，其它其它特定于提供者的鏈接類從該類派生，但它是一個抽象類。作為原形設計，它是有用的，但它不會直接在應用程序中使用。　　因此，為打開一個鏈接，必須使用下面的兩個方法之一：SqlConnection 方法和 OleDbConnection方法。假如目標是SQL Server 7.0, SQL Server 2000或更高版本，使用前者。假如目標是OLE DB提供者，就應當使用后者。假如需要通過ODBC驅動器訪問數據，就要使用ODBC .NET提供者的鏈接類（名為OdbcConnection）。　　要訪問SQL Server數據庫，使用直接治理提供者將產生更加有效的代碼。然而，注重假如需要訪問SQL Server6.5，那么就必須求助于OLE DB提供者，并使用OleDbXxx類和用于OLE DB的治理提供者。　　因此，在ADO .NET中有許多成對的類，如SqlConnection 和 OleDbConnection, SqlCommand 和 OleDbCommand, SqlDataReader 和 OleDbDataReader等等。盡管不同的對間最大的不同可能在于它的前綴，但假如說它們對編程接口是相同的，卻是不對的。　　可以確定的是，每對類做同樣的事情，但它們所有的接口反映的是底層的數據提供者。例如，在SqlConnection對象上沒有PRovider屬性，而在類中沒有PacketSize 或 WorkStationId 概念。　　在本文的后面部分，我將使用SQL Server治理提供者，這將意味著面向數據的ADO .NET類將帶有Sql前綴。在先前否認聲明有效的前提下，不需要對代碼進行修改或進行有限修改，它就能工作，對于由OLE DB提供者暴露的數據源也是一樣的。　　鏈接到數據源　　如同期望的那樣，需要鏈接對象將命令發送到SQL Server數據庫。從β2版開始，鏈接只能是SqlConnection類的對象。你將不再能通過向命令發送鏈接字符串，暗中創建鏈接對象。　　strConnString = "DATABASE=MyDB;SERVER=localhost;UID=sa;";
　　SqlConnection conn = new SqlConnection(strConnString);
　　strCmdText = "INSERT INTO MyTable VALUES (1, '1', 'One')"
　　SqlCommand cmd = new SqlCommand(strCmdText, conn);
　　在這段代碼片段中，我明確創建了一個鏈接對象，并將它與一個新的命令對象聯結起來。鏈接對象通過SqlCommand的Connection屬性暴露。　　在打開鏈接開始工作前，你可能要設置一些屬性。　　cmd.Connection.Open();　　在 ADO .NET中，鏈接對象的Open 方法不需要參數。　　至于鏈接對象的重用性，記住，ADO .NET提供了一種鏈接池。在以后的專欄中我將對它做進一步的討論，至于現在，你只要不必為節省對象的創建重用鏈接就可以了。不論何時客戶端需要一個鏈接，返回的是鏈接池中的對象。一旦鏈接關閉，對象不是留給碎片收集器，而是釋放到池中，供其它調用者使用。　　鏈接池不是由ADO .NET直接治理。SQL Server鏈接依靠Windows? 2000服務組件地pooling服務。每個鏈接池通過確切的匹配法則與不同的鏈接字符串相關。一旦創建，SQL Server鏈接池至到活動過程終止，它才會終結。　　相反，OLE DB鏈接被很小心的集中在OLE DB提供者會話對象的內部實現中。會話集中和自動收集是通過OLE DB服務完成，并通過注冊設置在每一個提供者基礎上被激活。因此，自動鏈接池并不會發生在所有OLE DB 提供者上，所有設備上。　　關于鏈接對象，最后要指出的是，鏈接類是不可繼續的。你不能從SqlConnection 或 OleDbConnection中創建一個新類。這樣做是出于代碼安全方面的考慮。然而，你可以創建你自己的類，在類中包含一個或多個鏈接對象。　　使用直接命令　　在向數據提供者發送命令前，要確保鏈接已經打開。默認鏈接是關閉的。然后，執行命令，只要有可能就關閉鏈接以確保其他客戶能得到重要資源。

　　SqlCommand類提供了用于執行命令的四個方法。它們是：ExecuteReader, ExecuteNonQuery, ExecuteScalar，及最新的但不是最小的，ExecutexmlReader。從本質上講，這些方法在期望的輸入上不同，返回的結果不同而已。通常，在操作完成后，需要確定使用的方法而不是繼續向前。　　順便指出，OleDbCommand 對象不支持ExecuteXmlReader。　　ExecuteReader用于執行選擇記錄的查詢命令或存儲過程。它返回一個或多個結果集。　　cmd.Connection.Open();
　　SqlDataReader dr = cmd.ExecuteReader();
　　// 處理結果集
　　cmd.Connection.Close();　　你可以通過SqlDataReader對象訪問選擇的記錄，使用Read方法在記錄間循環。使用NextResults方法移動到下一結果集。　　ExecuteNonQuery用于執行命令或存儲過程，它影響特定表的狀態。這只意味著一個查詢命令。通常使用此方法執行INSERT, UPDATE, DELETE, CREATE, SET語句。　　ExecuteNonQuery只返回命令所影響到的行數，假如得不到信息則返回-1。它并不能使你訪問語句或存儲過程生成的結果集。實際上，無法阻止你用此方法執行一條查詢命令，但在這種情況下，你既得不到結果集也得不到被影響的行數。　　cmd.Connection.Open();
　　nRecsAffected = cmd.ExecuteNonQuery();
　　cmd.Connection.Close();
　　//此處檢查影響到的記錄　　通過SqlCommand對象的RecordsAffected屬性可以得到影響到的行數。假如發生錯誤或假如執行的昌查詢命令，此屬性值為-1。　　ExecuteScalar期望執行查詢命令，或更可能是一個存儲過程，它返回數據。然而，此方法與ExecuteReader方法不同，它只將得到的結果集中的第一行第一列的值作為標量值返回。　　cmd.Connection.Open();
　　Object o = cmd.ExecuteScalar();
　　cmd.Connection.Close();
　　// work on the scalar here 　　此方法將值作為一個封裝對象返回。然后由你來解包或將此值造型為正確的期望類型。

　　假如需要對數據執行具有統計或集合性質的操作，ExecuteScalar方法將非凡有用。在這些或相似的情況下，你可能只希望返回給調用者一個值。由于它的使用場合，你或多或少的對存儲過程而不是單個SQL語句使用此方法。　　ExecuteXmlReader方法在SELECT命令執行后，構建并返回一個XmlReader對象，它利用了存在于SQL Server 2000中的XML特性。　　使用存儲過程　　到目前為止，對存儲過程討論得已經夠多了，是該看一下如何在ADO .NET中使用它了。在ADO .NET中調用存儲過程只與常規SQL語句稍微不同。　　你應當將存儲過程的名字指定為SqlCommand對象的命令文本。命令文本可以通過SqlCommand的構造函數或通過CommandText屬性指定。在下面的示例代碼中，存儲過程的名字是byroyalty。　　SqlCommand cmd = new SqlCommand("byroyalty", conn);
　　cmd.CommandType = CommandType.StoredProcedure;
　　SqlParameter par = new SqlParameter("@percentage", SqlDBType.Int);
　　par.Direction = ParameterDirection.Input;
　　par.Value = 15;
　　cmd.Parameters.Add(par);
　　SqlDataReader dr = cmd.ExecuteReader();
　　為幫助SqlCommand辨認出將執行的命令是一個存儲過程，應當將CommandType屬性設置為特定的值。　　CommandType.StoredProcedure　　它是在CommandType枚舉值（即可以在ADO .NET中使用的所有可以得到的命令類型）中的一個值。　　存儲過程可能需要一個或多個參數才能運行。在這種情況下，你需要使用SqlParameter類定義參數。　　參數具有@前綴名，并是與SQL Server兼容的類型。另外，它還要有一個方向：輸入，輸出還是兩種都有，當然它得是一個值。.NET 類型系統不同于SQL Server類型系統，你必須求助于SqlDbType枚舉列表得到正確的類型。例如，下面的片斷對.NET32位整型求值。　　SqlDbType.Int 　　SqlCommand 類擁有Parameters集合，此集合為SQL命令的占位符和存儲過程是定義的所有參數存儲實際的值。要向集合中增加參數，只需調用add方法。注重，假如你以SQL Server治理提供者或用于OLE DB .NET提供者的位置標記為目標，那么在命令命令文本中你必須使用已命名的參數。　　存儲過程的輸出然后通過你所使用的ExecuteXXX方法提供的接口進行治理。　　其它 SqlCommand 屬性　　下面介紹在SqlCommand類中發現的其它有趣的屬性。　　一條命令在過一定時間后就會超時。假如你知道要經過很長的操作，你就可能希望設置這種限制。象ADO中那樣，檢查的屬性是CommandTimeout，其默認值是30秒。　　與ADO不同，ADO .NET使你可通過CommandBehavior枚舉指定命令的期望行為。這樣的值指定了對結果的描述，并指定查詢如何影響數據源。在β1版本中，可以為每個命令設置CommandBehavior屬性。從β2版開始，只能使用CommandBehavior枚舉值作為ExecuteReader的參數。　　對于其它選項，你可以使用查詢命令限制獲得的要害字和結構信息。在這種情況下，命令執行時不會對選擇的行進行鎖定。這種行為是由KeyInfo標記設定的。　　作為可選項，可能只需得到列信息，而不通過加鎖影響數據庫的狀態。這個選項是SchemaOnly。另一個選項，SingleResult，使你能夠指定只返回一個結果集，而不論命令可以得到多少個結果集。在這種情況下，命令只返回找到的第一個結果集。第四個選項是CloseConnection，它強迫SqlDataReader對象與一個查詢命令聯結起來，以期望在Close方法的最后一步自動關閉鏈接。　　服務器指針　　先前提到過，在ADO .NET中不支持服務器指針。假如需要使用服務器指針，并且負擔不起在沒有它的情況下重建應用程序，唯一的辦法是通過ADO對象。要這樣做，需要導入ADODB類型庫，為不同的對象創建恰當的.NET封裝，然后與它們連接起來。然而，在這種情況下，你無法利用ADO .NET的優勢。　　這樣做原因很簡單。服務器指針必須與數據庫服務器的底層行為相適應。當處于鏈接時，并不是所有的DBMS以同樣的方式工作。這樣不同特性的對數據庫不可知的實現已經證實是非常困難的。為了避免出現更進一步的問題，ADO .NET沒有為服務器指針暴露通用的類，從而從根本上消除了這種問題。　　然而，用于SQL Server的治理提供者在將來的發行版中將支持服務器指針，其它類型的治理提供者也會發生同樣的事情。因此，ADO .NET對服務器指針支持的最后回答是，它將提供支持，但是將通過其實現與底層工作方式非常匹配的類以一種嚴格的完全DBMS方式（提供支持）。　　總結　　在ADO .NET中瀏覽數據的方式并不真正與在ADO中的方式不同。你仍需要創建鏈接，發送命令。在本文中，我提到了表示直接SQL命令的類，你可以使用它們執行存儲過程。

上一篇：使用UML設計數據庫應用

下一篇：ADO.NET實現應用程序數據訪問層