一段时间以来，存储过程一直是企业应用程序开发数据访问的首选方法。存储过程的安全性更高、封装能力更强，并能执行复杂的逻辑，且不会打乱应用程序代码。但是，它也存在一些缺点：

• 开发者倾向于在存储过程中加入商业逻辑。

• 更改过程时必须改变开发环境。

• 查找过程所需的参数比较费时。

• 许多时候，存储过程提供的功能超出所需。

嵌入到应用程序代码中的内联SQL代码是数据访问的另一个常见方法。虽然企业在开发过程中很少用到这种方法，但许多小型项目应用这种类型的数据访问方法。应用内联SQL可以实现快速开发，但它并不具有存储过程的安全与封装优势。

参数化查询介于存储过程与内联SQL之间。它为数据访问程序开发提供一种安全、封装性的方法，并允许你利用内联SQL的快速开发优势。

如何应用参数化查询

应用参数化查询并不那么容易。例如，下面的代码（图A）说明如何编写参数化查询：

在这个例子中，我们选择所有具有指定CustomerID的用户。注意，这个过程与在一个存储过程中编写Select语句十分相似。其不同在于你将它直接嵌入你的应用程序代码或源文件中。（我们稍后再讨论源文件。）

为使ADO.NET能够移植@CustomerID参数，你只需简单建立一个正常的SqlParameter并将它加入到当前命令的SqlCommand.Parameters集中。然后你就可在希望的连接上执行命令，ADO.NET则建立在SQL服务器上执行的命令。下面的代码片断（图B）是一个说明如何建立并执行整个命令的例子：

如你所见，建立并执行参数化查询是一个非常简单的过程。在数据访问库——如微软的数据应用程序块——的辅助下，这个过程可以进一步简化。

参数化查询的缺点

说到编程，每种方法都有其优缺点，决定应用参数化查询也不例外。它的一个主要的缺点在于：由于查询被嵌入到应用程序代码中，可能在几个地方都以同样的查询结束。我可以建立一个存储查询的中心位置来消除这种重复。这个位置可以是一个XML文件、在应用程序中的一个带公共静态字符串成员的类、一个自定义的.NET属性、或者是一个空文件。应用这些技巧，你就可以在执行前查找到所需的查询。

应用参数化查询的另一个潜在问题是许多公司并不允许在其应用程序（以及数据层）中使用内联SQL。我认为这是因为人们在谈论将SQL插入应用程序代码时，他们指的是特别（内联）代码，而不是参数化查询。这样的规则也使DBA对在SQL服务器上执行代码有了更大的控制权，这对大型数据库十分有利。

何时应使用参数化查询？

在任何需要在SQL服务器上执行操作的情况下，你都可以应用参数化查询。但是，参数化查询主要应用于需要执行的创建、阅读、更新与删除(CRUD)操作。如果你在执行需要较长时间或由不同SQL语句构成的复杂操作，最好将此操作保留在SQL服务器中。

虽然参数化查询在许多情况下应用起来十分方便，但由于它可能会打乱你的应用程序代码，所以我并不推荐你在复杂的数据操作逻辑中应用它。当你的应用程序代码被打乱时，你必然会遇到严重的代码维护问题。

在编写数据访问程序的许多情况下，与特别查询与存储过程相比，参数化进程不失为一个较好的选择。参数化查询介于其他两种选择之间，如果应用得当，能够显著提高开发效率。