我一直都不喜欢在访问数据库时采用拼接SQL的方法，原因有以下几点： 1. 不安全：有被SQL注入的风险。 2. 可能会影响性能：每条SQL语句都需要数据库引擎执行[语句分析]之类的开销。 3. 影响代码的可维护性：SQL语句与C#混在一起，想修改SQL就得重新编译程序，而且二种代码混在一起，可读性也不好。 所以我通常会选择【参数化SQL】的方法去实现数据库的访问过程，而且会将SQL语句与项目代码（C#）分离开。 不过，有些人可能会说：我的业务逻辑很复杂，Where中的过虑条件不可能事先确定，因此不拼接SQL还不行。 看到这些缺点，ORM用户可能会认为：使用ORM工具就是终极的解决方案。 是的，的确ORM可以解决这些问题。 但是，解决方案并非只有ORM一种，还有些人就是喜欢写SQL呢。 所以，这篇博客不是写给ORM用户的，而是写给所有喜欢写SQL语句的朋友。 [b]CPQuery是什么？[/b] 看到博客的标题，你会不会想：CPQuery是什么？ 下面是我的回答： 1. CPQuery 是一个缩写：Concat Parameterized Query 2. CPQuery 可以让你继续使用熟悉的拼接方式来写参数化的SQL 3. CPQuery 是我设计的一种解决方案，它可以解决拼接SQL的前二个缺点。 4. CPQuery 也是这个解决方案中核心类型的名称。 希望大家能记住CPQuery这个名字。 [b]CPQuery适合哪些人使用？[/b] 答：适合于喜欢手写SQL代码的人，尤其是当需要写动态查询时。 [b]参数化的SQL语句[/b] 对于需要动态查询的场景，我认为：拼接SQL或许是必需的，但是，你不要将数值也拼接到SQL语句中嘛，或者说，你应该拼接参数化的SQL来解决你遇到的问题。 说到【拼接参数化SQL】，我想解释一下这个东西了。 这个方法的实现方式是：拼接SQL语句时，不要把参数值拼接到SQL语句中，在SQL语句中使用占位符参数，具体的参数值通过ADO.NET的command.Parameters.Add()传入。现在流行的ORM工具应该都会采用这个方法。 我认为参数化的SQL语句可以解决本文开头所说的那些问题，尤其是前二个。对于代码的维护问题，我的观点是：如果你硬是将SQL与C#混在一起，那么参数化的SQL语句也是没有办法的。如果想解决这个问题，你需要将SQL语句与项目代码分离，然后可以选择以配置文件或者存储过程做为保存那些SLQ语句的容器。 所以，参数化的SQL并不是万能的，代码的可维护性与技术的选择无关，与架构的设计有关。任何优秀的技术都可能写出难以维护的代码来，这就是我的观点。 改造现有的拼接语句 还是说动态查询，假设我有这样一个查询界面： [img]http://files.jb51.net/file_images/article/201209/201209191133282.png[/img] 显然，在设计程序时，不可能知道用户会输入什么样的过滤条件。 因此，喜欢手写SQL的人们通常会这样写查询：