Question

我目前正在处理的应用程序会生成大量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并在运行时将它们参数化作为重写整个应用程序的停止间隙。

Answer 1

不要这样做。这太过分了。此外，这种方法存在大量安全风险。

至少查看Command对象和参数化查询。

Here is a small tutorial.

Answer 2

现在重构。

如果你认为这个抽象层能够更快更容易地进入，你就是在欺骗自己。在内心深处，你知道这会增加项目的风险和不确定性，但是你想要消除SQL注入问题或者你用魔法子弹打架的任何问题。

您可以花时间编写这个新的解析子系统并对系统进行回归测试，您可以使用对数据库中相对较少的代码生成和测试的SP的调用来替换所有内联代码。另外，你可以一块一块地做到。

为什么要构建一个重要的一次性代码，这些代码很难调试，并且与最终的架构看起来不一致？

Answer 3

我会建议使用Command参数来做你想要的。任何类型的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

Answer 4

认为你的任务太过荣耀...... 你应该创建一个非常强大的解析器......我认为开始重写应用程序，找到生成查询的点并重构代码会更好更容易。

Good Loock！

Answer 5

我只能想到即时参数化查询会带来的一个好处：它会减少应用程序当前的SQL注入攻击漏洞。在其他任何方面，你可能希望的最好的是这个假设的即时解析器/解释器不会破坏任何东西。

即使你不必自己写这样的东西（我打赌你这样做），这对于引入生产系统来说是一个相当大的风险，特别是因为它是一个权宜之计，当你重构时会被丢弃。应用程序。 SQL注入攻击的风险是否足以证明这一点？

Answer 6

您是否考虑过对旧代码运行替换正则表达式？将从当前查询中提取值，用参数替换它们的东西，并在查询行后追加Command.Parameters.AddWithValue（paramName，paramValue）调用，如果当前内联SQL都遵循相同的值（或者如果所有这些都可以，你可以在你最喜欢的编辑器中修复剩下的部分。

解析T-SQL以参数化查询

6 个答案: