大家在使用ADO過程中，發(fā)現(xiàn)了許多ADO缺點(diǎn)，建立并執(zhí)行參數(shù)化查詢是一個(gè)非常簡單的過程。在數(shù)據(jù)訪問庫——如微軟的數(shù)據(jù)應(yīng)用程序塊——的輔助下，這個(gè)過程可以進(jìn)一步簡化。

參數(shù)化查詢的ADO缺點(diǎn)

說到編程，每種方法都有其優(yōu)缺點(diǎn)，決定應(yīng)用參數(shù)化查詢也不例外。它的一個(gè)主要的缺點(diǎn)在于：由于查詢被嵌入到應(yīng)用程序代碼中，可能在幾個(gè)地方都以同樣的查詢結(jié)束。我可以建立一個(gè)存儲(chǔ)查詢的中心位置來消除這種重復(fù)。這個(gè)位置可以是一個(gè)XML文件、在應(yīng)用程序中的一個(gè)帶公共靜態(tài)字符串成員的類、一個(gè)自定義的.NET屬性、或者是一個(gè)空文件。應(yīng)用這些技巧，你就可以在執(zhí)行前查找到所需的查詢。#t#

應(yīng)用參數(shù)化查詢的另一個(gè)潛在問題是許多公司并不允許在其應(yīng)用程序（以及數(shù)據(jù)層）中使用內(nèi)聯(lián)SQL。我認(rèn)為這是因?yàn)槿藗冊谡務(wù)搶QL插入應(yīng)用程序代碼時(shí)，他們指的是特別（內(nèi)聯(lián)）代碼，而不是參數(shù)化查詢。這樣的規(guī)則也使DBA對在SQL服務(wù)器上執(zhí)行代碼有了更大的控制權(quán)，ADO缺點(diǎn)這對大型數(shù)據(jù)庫十分有利。

何時(shí)應(yīng)使用參數(shù)化查詢？

在任何需要在SQL服務(wù)器上執(zhí)行操作的情況下，你都可以應(yīng)用參數(shù)化查詢。但是，參數(shù)化查詢主要應(yīng)用于需要執(zhí)行的創(chuàng)建、閱讀、更新與刪除(CRUD)操作。如果你在執(zhí)行需要較長時(shí)間或由不同SQL語句構(gòu)成的復(fù)雜操作，***將此操作保留在SQL服務(wù)器中。

雖然參數(shù)化查詢在許多情況下應(yīng)用起來十分方便，但由于它可能會(huì)打亂你的應(yīng)用程序代碼，所以我并不推薦你在復(fù)雜的數(shù)據(jù)操作邏輯中應(yīng)用它。當(dāng)你的應(yīng)用程序代碼被打亂時(shí)，你必然會(huì)遇到嚴(yán)重的代碼維護(hù)問題。

在編寫數(shù)據(jù)訪問程序的許多情況下，ADO缺點(diǎn)與特別查詢與存儲(chǔ)過程相比，參數(shù)化進(jìn)程不失為一個(gè)較好的選擇。參數(shù)化查詢介于其他兩種選擇之間，如果應(yīng)用得當(dāng)，能夠顯著提高開發(fā)效率。