将SQL查询存储在资源文件中是不好的做法吗？

Question

我有一个与SQL服务器通信的Web应用程序.我没有硬编码所有查询字符串,而是选择将它们存储在全局资源文件中.那被认为是不好的做法吗？

另外,当我这样做时,尽管那些查询被参数化(更不用说资源文件中的"拼写"警告),Visual Studio仍然向我大肆宣传SQL注入的可能性.

Answer 1

实践属于范围(例如避免,喜欢,使用等)并且取决于背景.

如果你从高处获得了一个不能使用存储过程的任务,你也不能使用ORM,那么将复杂的SQL存储为资源并不是很糟糕,因为你至少不必转义字符在a System.String和你至少保持它有点安全的眼睛.如果您的SQL本质上是动态的,那么将资源文件与文本模板机制相结合是相当干净的.

也就是说,除非在维护成本,可读性和功能方面有明显的好处,否则应该避免使用资源文件(通常在大多数情况下).将存储过程绑定到代码有很多简洁的方法; 有许多称职的ORM工具和迷你数据访问层可能会做得更好.

Answer 2

将SQL查询与应用程序代码分开是一件好事.存储过程是执行此操作的常规方法,但如果这不可行并且您必须直接使用SQL,我认为您的方法很好.最新版本的SQL Server参数化查询在第一次运行时进行预编译,并提供与SP类似的性能.

但是我建议你研究其他数据访问方法,例如linq-to-sql,它可以自动生成SQL查询,并为代码提供更清晰的界面.

Answer 3

资源文件definitley不是这个地方.资源文件的要点是可以本地化(即被其他语言/文化定义的其他资源文件覆盖)的事物的集中存储库.

例如,你把一个字符串"Hello"放在一个X.resources.dll,但是你也可以创建一个es-ES\X.resources.dll西班牙语,其中字符串会"Hola"改为 - 然后当你的应用程序查询字符串时,它将获得与语言/文化匹配的任何版本用户的操作系统配置.

如果您希望在不重新编译代码的情况下轻松更改SQL,请将其放入您App.config的ConfigurationManager类中并使用该类来读取它.如果您不希望它在没有代码重新编译的情况下可以更改,那么只需将事物硬编码为static/ const string.也就是说,理想当然是制作真正的存储过程.