我目前正在处理的应用程序会生成大量 SQL 内联查询。然后将所有生成的 SQL 移交给数据库执行类。我想为数据执行类编写一个解析服务，它将接受这样的查询：
SELECT field1, field2, field3 FROM tablename WHERE foo=1 AND bar="baz"
并把它变成这样的东西：
SELECT field1, field2, field3 FROM tablename WHERE foo=@p1 AND bar=@p2 blah blah blah
在 c# 或 vb.net 中已经写过任何可以为我完成此任务的东西吗？这是为这个项目重构 DAL 之前的一个权宜之计。
更新：伙计们，我有一个从经典 ASP 移植到 ASP.NET 的巨大应用程序，其中包含数千行内联 SQL。唯一的优点是所有生成的 sql 都交给了数据执行类。我想在执行之前捕获 sql 并动态参数化它们作为重写整个应用程序的权宜之计。
现在重构。
如果您认为这一抽象层能够更快、更容易地进入，那您就是在自欺欺人。在内心深处，你知道这会增加项目的风险和不确定性，但你想用灵丹妙药解决 SQL 注入问题或任何你正在解决的问题。
在您编写这个新的解析子系统和对系统进行回归测试时，您可能会用调用数据库上相对较少的代码生成和测试的 SP 来替换所有内联代码。另外，你可以一块一块地做。
为什么要构建一段难以调试且与您希望最终架构看起来不完全一致的重要一次性代码？
我会建议使用命令参数来做你想做的事。任何类型的 SQL 查询字符串解析都只是要求有人与您一起玩 SQL 注入游戏。示例代码如下。参数集合很容易以正常方式操作
command.CommandText = "SELECT * FROM table WHERE key_field='?'"
command.Parameters.Append command.CreateParameter(, 8, , , "value") '8 is adBSTR value
set rsTemp = command.Execute
o 认为你的任务太光荣了......你应该创建一个非常强大的解析器......我认为开始重写应用程序、查找生成查询的点和重构代码会更好、更容易。
好锁！
我只能想到动态参数化查询会带来的一个好处：它将减少您的应用程序当前对 SQL 注入攻击的脆弱性。在其他所有方面，您可能希望的最好结果是这个假设的动态解析器/解释器不会破坏任何东西。
即使您不必自己编写这样的东西（我敢打赌您确实这样做了），将其引入生产系统也是一个相当大的风险，特别是因为它是一种权宜之计，在您重构应用程序时将被丢弃。SQL 注入攻击的风险是否足以证明这一点？
您是否考虑过在旧代码上运行替换正则表达式？如果当前的内联 SQL 都遵循相同的值（或者几乎所有这些都可以，您可以在您最喜欢的编辑器中修复其余部分）。