问题
JDBC兼容的应用程序应该在哪里存储其SQL语句？为什么？
到目前为止，我设法确定了以下选项：
- 在业务对象中硬编码
- 嵌入在SQLJ子句中
- 封装在不同的类中，例如数据访问对象
- 元数据驱动(将对象模式与数据模式分离 - 描述元数据中它们之间的映射)
- 外部文件(例如属性或资源文件)
- 存储程序
每个人的"优点"和"缺点"是什么？
SQL代码应该被视为"代码"还是"元数据"？
存储过程是否应仅用于性能优化，还是数据库结构的合法抽象？
性能是决定的关键因素吗？那么vendor lock-in呢？
什么是更好的 - 松耦合或紧耦合，为什么？
编辑：谢谢大家的答案 - 这是一个总结：元数据驱动，即对象关系映射(ORM)
优点：
- 非常抽象 - 无需更改模型即可切换数据库服务器
- 广泛传播 - 几乎是一种标准
- 减少所需的SQL数量
- 可以将SQL存储在资源文件中
- 性能(通常)是可以接受的
- 元数据驱动的方法
- (数据库)供应商独立性
缺点：
- 隐藏SQL和真正的开发人员的意图
- DBA很难对SQL进行审查/更改
- 对于奇怪的情况，可能仍然需要SQL
- 可以强制使用专有查询语言，例如HQL
- 不适合优化(抽象)
- 缺乏参照完整性
- 替代缺乏SQL知识或缺乏对DB中代码的关注
- 永远不会匹配本机数据库性能(即使它接近)
- 模型代码与数据库模型非常紧密
硬编码/封装在DAO层中
优点： - SQL保存在访问数据的对象中(封装)
- SQL很容易编写(开发速度)
- 在需要更改时，可以轻松跟踪SQL
- 简单的解决方案(没有凌乱的架构)
缺点：
- DBA无法查看/更改SQL
- SQL很可能成为特定于数据库的
- SQL可能变得难以维护
存储过程
优点： - SQL保存在数据库中(靠近数据)
- DBMS对SQL进行了解析，编译和优化
- DBA易于查看/更改SQL
- 减少网络流量
- 提高安全性
缺点：
- SQL绑定到数据库(供应商锁定)
- SQL代码难以维护
外部文件(例如，属性或资源文件)
优点 - 无需重建应用程序即可更改SQL
- 将SQL逻辑与应用程序业务逻辑分离
- 所有SQL语句的中央存储库 - 更易于维护
- 更容易理解
缺点：
- SQL代码可能变得无法维护
- 更难检查SQL代码(语法)错误
嵌入在SQLJ子句中
优点： - 更好的语法检查
缺点：
- 与Java密切相关
- 性能低于JDBC
- 缺乏动态查询
- 不那么受欢迎
#1 热门回答(24 赞)
通常，应用程序在大小和/或可重用性方面增长得越多，就需要对SQL语句进行外部化/抽象化。
硬编码(作为静态最终常量)是第一步。下一步是存储在文件(properties / xml文件)中。元数据驱动(由像Hibernate / JPA这样的ORM完成)是最后一步。
硬编码的缺点是你的代码可能会特定于数据库，并且你需要在每次更改时重写/重建/重新分配。优点是你有一个地方。
存储在文件中的缺点是，当应用程序增长时，它可能变得不可维护。优点是你不需要重写/重建应用程序，除非你需要添加额外的DAO方法。
元数据驱动的缺点是你的模型代码与数据库模型非常紧密。对于数据库模型中的每个更改，你都需要重写/重建/重新分发代码。优点是它非常抽象，你可以轻松地从数据库服务器切换而无需更改你的模型(但现在问问自己：公司多久从数据库服务器切换一次？可能至少每3年一次，不是'是吗？)。
我不会将存储过程称为"好"的解决方案。他们的目的完全不同。即使你的代码依赖于所使用的DB /配置。
#2 热门回答(19 赞)
我不知道这是否是最佳的，但根据我的经验，他们最终在DAO层中硬编码(即字符串文字)。
#3 热门回答(11 赞)
通过使用ORM(例如hibernate)，你希望无需担心SQL语句。性能通常是可以接受的，你也可以获得供应商独立性。