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

【问题标题】：What is the best strategy to avoid hard coded SQL statements避免硬编码 SQL 语句的最佳策略是什么
【发布时间】：2009-03-17 16:31:52
【问题描述】：

前几天我向一位同事展示了一些我正在编写的代码，他顺便评论说我有硬编码的 SQL 语句。现在这些 SQL 语句是非常静态的，而那些确实倾向于改变的语句我在数据库上创建了视图，并且有一个硬编码的“从视图中选择列''”之类的事情。

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

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

编辑：在这种情况下，我使用 .Net2.0 与 SQL Server 2005 和 Oracle 数据库交互

【问题讨论】：

你说的是 SQL Server 吗？甲骨文？您使用的是哪个版本的 .NET？
仅仅说“我想避免硬编码的 SQL 语句”是不够的，因为有很多方法可以做到这一点。但是，如果您弄清楚硬编码 SQL 给您带来了哪些问题，那么有人可以提供一个很好的答案，而不仅仅是他们碰巧做了什么。

标签： .net

【解决方案1】：

【讨论】：

将硬编码的 sql 从代码移动到存储过程中的硬编码 sql？同样的事情，如果您更改数据库结构，则两个位置的 sql 都会中断，并且在任何一种情况下您都不知道。 ORM 几乎就是答案，因为它强制通过您的代码进行级联更改...
我完全同意。但是，您必须查看直接从硬编码 SQL 到使用 ORM 的逻辑，因此是“更陡峭的学习曲线”点。不是每个人都能跳。如果您要对 SQL 语句进行硬编码，那么它们最好放在最不痛苦的地方。

【解决方案2】：

您确实应该为特定的数据模型构建应用程序。

如果您的底层数据模型发生更改，这是唯一需要更改 SQL 语句的事情，那么确实无法避免也进行代码更改。

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

【讨论】：

【解决方案3】：

我不惜一切代价避免使用更难编码的 SQL。我更喜欢调用存储过程。

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

【讨论】：

【解决方案4】：

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

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

如果您不使用存储过程或 ORM 工具，可以通过多种方式对硬编码的 sql 语句进行参数化。这是推荐的做法。

如果您使用的是 MSSql 2005+，那么根据我所看到和测试的情况，您的硬编码语句仍将缓存其执行计划。还有一些可以使用的提示（例如 OPTIMIZE FOR UNKNOWN），这将有助于提高性能。

评估您的环境和数据层的变化量，无论哪种方式，您都应该没问题。

【讨论】：

【解决方案5】：

一些想法：

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

【讨论】：