我知道每种方法都有利有弊，但是在放置 SQL 语句的位置是否有最佳实践？我一直将它们放在 Java 类中，但我来到了一个项目，它们通过 Spring 字符串构造函数注入。原因是如果 SQL 语句在应用程序上下文中，您不必删除所有的 " 和 + 来让 SQL 复制/粘贴到服务器上。我认为这不是一个很好的理由，但是这就是我目前介入的。我知道这也可以通过属性来完成。
所以我的问题是 SQL 语句应该放在应用程序上下文、Java 文件、属性文件还是我没有想到的某个地方？
更新：
从我得到的回复来看，准备好的语句似乎是 SQL 语句的最佳位置。但是动态生成的 SQL 语句呢？代码将有许多不同的字符串，这些字符串都将连接在一起以根据传入的内容进行查询。如果我们有一个可以传入（或不传入）的具有 6 个输入参数的方法，我将需要大量的准备好的陈述来说明所有的可能性。
我曾考虑过使用诸如 Hibernate 之类的 ORM 工具，但我正在使用 iSeries 数据库并且表的构造并不好。也许有一天我可以重写 Hibernate 并写出 900 行 SQL 语句......但一步一步。
同意 Thiharas 的回答，但为什么不更进一步，将它们保存在应用程序中的 .sql 文件中。每个查询都有自己的文件，因此更易于管理。
当然，如果像 Hibernate 这样的 ORM 框架不适合您的应用程序的话。
关于哪里是最好的地方没有规定：这就像“把我的钥匙放在家里最好的地方”。
如果您的项目需要您从应用程序外部访问 SQL，那么为什么不将它们放在属性文件中。在这种情况下，您可能希望通过执行一些 JUnit 测试来检查 Sql 中的更改是否仍然与您的应用程序兼容。
存储过程因其执行速度而好，但不好，因为它们将您的应用程序配置拆分为两个地方。此外，它们与数据库软件紧密耦合（这又取决于项目可能是好事还是坏事）
希望我的回答能帮助您根据自己的情况向自己提出正确的问题。
最好的问候， 齐德
这不是唯一的原因。当 SQL 语句在 Java 代码之外时，您可以更改它而无需重新编译和部署您的应用程序。如果查询是定期从文件中加载的（比如每 8 小时一次），那么您甚至不必重新启动服务器。这对于从事生产应用程序支持的人来说将是非常有益的。
同样关于第一个原因，您认为这不是一个好的理由；当您必须调试一个大型 SQL 语句并需要将其粘贴到查询执行器中时，删除所有+和 '"' 标志，我相信您会改变主意 :-)