避免硬编码SQL语句的最佳策略是什么？

Question

前几天我向同事展示了我正在处理的一些代码，并且在传递过程中他评论了我有硬编码的SQL语句这一事实。现在这些SQL语句是非常静态的，并且那些确实倾向于改变的我在数据库中创建了视图，并且有一个硬编码的“从视图中选择列”这种事情。

所以我的问题是在这些情况下最佳做法是什么？

是将SQL语句作为资源添加到项目中，然后在代码中调用资源吗？有更好的方法吗？

编辑：在这种情况下，我使用.Net2.0

与SQL Server 2005和Oracle数据库进行交互

Answer 1

1. 存储过程。防止注射，维护等各种可能的问题。将数据库代码放在数据库代码所在的位置。

2. ORM工具（如Hibernate，Subsonic等）意味着你永远不会看到一行T-SQL。陡峭的学习曲线，但是一个很好的做法，尽早开始，而不是以后。

Answer 2

我不惜一切代价避免使用更难编码的SQL。我更喜欢称商店程序。

如果您使用的是.NET 3.5和MS SQL Server，您可能会查看LINQ，然后您的SQL语句就会出现在代码中。

Answer 3

你真的应该为特定的数据模型构建应用程序。

如果您的基础数据模型发生了变化，这是唯一需要更改SQL语句的内容，那么实际上也无法避免进行代码更改。

我认为硬编码的SQL语句没有任何问题。有一些代码生成器用于处理数据库，但您仍然需要围绕特定的已知数据模型进行设计，因此如果模型发生更改，您仍然会遇到相同的问题 - 代码必须更改。

Answer 4

这实际上取决于您的数据模型以及您对数据库的权限。我去过那些不允许他们的.Net开发人员编写Stored Procs并且只允许一组精选数据库开发人员这样做的公司。

与Frakkle提到的一样，如果您的数据模型不经常更改，那么很可能硬编码语句不会成为问题。

如果不使用存储过程或ORM工具，有一些方法可以参数化硬编码的sql语句。这是推荐的做法。

如果您正在使用MSSql 2005+，那么从我看过和测试过的，您的硬编码语句将仍然会缓存其执行计划。还有一些提示可以使用（如OPTIMIZE FOR UNKNOWN），这将有助于提高性能。

评估您的环境以及数据层的变化量，无论您走到哪里，都应该没问题。

Answer 5

一些想法：

1. 在数据库级别，限制应用程序用户执行除存储过程之外的对象。
2. 使用数据库库将SP绑定到类，或仅适用于SP。
3. 编码政策与代码评论/演练相结合。

这些可能不是最友好的方法，但它们确实在某些环境中具有价值。