框架設計之ADO.NET Command的ExecuteScalar誤用情景及底層解說

最近下載了點資料，學了學Android，發現Android入門還算簡單，從.NET過渡到Android，也就三七十一天的事。

大伙有空也可以學學。。。

好了，言歸正文，那日，有網友發了一個他們公司的數據層框架的DLL，讓我審視（Reflector查看如下）：

 

炸一看框架，支持的數據庫種類繁多，看來寫框架的人涉及面還挺廣的。

往里一看，比較悲催，有廣度而無深度，另外數據庫種類的dll需要提前引用，那是相當浩大的數據庫工程：

 

框架具體就不過多點評了，在不經意思間，本人看到有一個閃光點，覺的可以和大伙分享分享：

1：檢測某列是否存在： 

2：檢測某表是否存在： 

 

這是一條判斷某字段列和某表是否存在的方法，此處用了select X from table的方式，然后調用了GetSingle(sql)。

而 GetSingle的代碼如下：

 

代碼里，關於ADO.net的相關對象沒提升到全局變量以重用這個不是講的重點，就先忽略先，今天分享的知識點是ExecuteScalar：

對於ADO.NET的Command命令，有三個方法，大伙很熟悉：

 

 
          1：ExecuteDataReader，返回數據流，用於列表讀取。 
          
 
          2：ExecuteScalar，返回首行首列。 
          
 
          3：ExecuteNonQuery，返回首影響的行。 
         

 

解說： 

 

           如果我們從語義上講，用ExecuteScalar執行一條select *  
          from table,只返回首行首列，看似還過的去，然實際不然。 
          
實際上，后面的ExecuteScalar，或是ExecuteNonQuery，內部都是調用的ExecuteDataReader來處理的，見如下代碼即知： 
         

 

 

說明分析： 

           微軟並沒有什么特殊照顧，所以原來的語句，仍會到數據庫里，按語句的要求，並找出全部滿足條件的數據流進行返回。 
          
當然，值的欣慰的是，DataReader是一個流數據傳輸，它並不是一次性傳輸所有數據，而是部分段傳輸。 
         

 

中間我做了一個小測試，大體過程是這樣的：

           使用DataReader去讀取數據返回一個SqlDataReader，然后斷點，接着把數據庫服務給停了，然后繼續調試，發現數據還可以正常讀取。 
          
說明還未讀取之時，部分數據就先通過管道把數據從數據庫傳輸到程序的內存中了，后來按F5繼續，讀取后面就會拋進程管道已關閉的錯誤。 
         

 

總結：

本文說明兩點使用方法上的兩點：

 
          1： 本來是Top  
          1 的語句，結果變成Select *，這兩條語句在數據庫端執行，性能的差異不說大伙也懂了。 
          
 
          2： ExecuteScalar雖然是返回首行首列，但實際返回的是個DataReader，如果你查詢的是列表，實際上內存傳輸了列表，只是最終你程序讀取了列表中的第一個字節。 
          
當然了，由於流的傳輸，並不一次性傳輸全部，只是部分段傳輸，所以性能的損失並不是太明顯。  
         

 

 

要寫好底層框架，任重而道遠，望大伙再接再勵。