• 開發者傾向於在存儲過程中加入商業邏輯。
• 更改過程時必須改變開發環境。
• 查找過程所需的參數比較費時。
• 許多時候，存儲過程提供的功能超出所需。
嵌入到應用程序代碼中的內聯SQL代碼是數據訪問的另一個常見方法。雖然企業在開發過程中很少用到這種方法，但許多小型項目應用這種類型的數據訪問方法。應用內聯SQL可以實現快速開發，但它並不具有存儲過程的安全與封裝優勢。
參數化查詢介於存儲過程與內聯SQL之間。它爲數據訪問程序開發提供一種安全、封裝性的方法，並允許你利用內聯SQL的快速開發優勢。
如何應用參數化查詢
應用參數化查詢並不那麼容易。例如，下面的代碼（圖A）說明如何編寫參數化查詢：
圖A 參數化查詢
在這個例子中，我們選擇所有具有指定CustomerID的用戶。注意，這個過程與在一個存儲過程中編寫Select語句十分相似。其不同在於你將它直接嵌入你的應用程序代碼或源文件中。（我們稍後再討論源文件。）
爲使ADO.NET能夠移植@CustomerID參數，你只需簡單建立一個正常的SqlParameter並將它加入到當前命令的SqlCommand.Parameters集中。然後你就可在希望的連接上執行命令，ADO.NET則建立在SQL服務器上執行的命令。下面的代碼片斷（圖B）是一個說明如何建立並執行整個命令的例子：
圖B 整個命令
如你所見，建立並執行參數化查詢是一個非常簡單的過程。在數據訪問庫——如微軟的數據應用程序塊——的輔助下，這個過程可以進一步簡化。
參數化查詢的缺點
說到編程，每種方法都有其優缺點，決定應用參數化查詢也不例外。它的一個主要的缺點在於：由於查詢被嵌入到應用程序代碼中，可能在幾個地方都以同樣的查詢結束。我可以建立一個存儲查詢的中心位置來消除這種重複。這個位置可以是一個XML文件、在應用程序中的一個帶公共靜態字符串成員的類、一個自定義的.NET屬性、或者是一個空文件。應用這些技巧，你就可以在執行前查找到所需的查詢。
應用參數化查詢的另一個潛在問題是許多公司並不允許在其應用程序（以及數據層）中使用內聯SQL。我認爲這是因爲人們在談論將SQL插入應用程序代碼時，他們指的是特別（內聯）代碼，而不是參數化查詢。這樣的規則也使DBA對在SQL服務器上執行代碼有了更大的控制權，這對大型數據庫十分有利。
何時應使用參數化查詢？
在任何需要在SQL服務器上執行操作的情況下，你都可以應用參數化查詢。但是，參數化查詢主要應用於需要執行的創建、閱讀、更新與刪除(CRUD)操作。如果你在執行需要較長時間或由不同SQL語句構成的複雜操作，最好將此操作保留在SQL服務器中。
雖然參數化查詢在許多情況下應用起來十分方便，但由於它可能會打亂你的應用程序代碼，所以我並不推薦你在複雜的數據操作邏輯中應用它。當你的應用程序代碼被打亂時，你必然會遇到嚴重的代碼維護問題。
在編寫數據訪問程序的許多情況下，與特別查詢與存儲過程相比，參數化進程不失爲一個較好的選擇。參數化查詢介於其他兩種選擇之間，如果應用得當，能夠顯著提高開發效率。