兼容JDBC的应用程序应在哪里存储其SQL语句，为什么？

到目前为止，我设法确定了这些选项：

• 硬编码在业务对象中
• 嵌入在SQLJ子句中
• 封装在单独的类中，例如 数据访问对象
• 驱动元数据（将对象模式与数据模式分离-在元数据中描述它们之间的映射）
• 外部文件（例如属性或资源文件）
• 存储过程

各自的“优点”和“缺点”是什么？

应该将SQL代码视为“代码”还是“元数据”？

存储过程应该仅用于性能优化还是它们是数据库结构的合法抽象？

性能是决定的关键因素吗？什么厂商锁定？

更好的是松耦合还是紧耦合，为什么？

编辑：谢谢大家的答案–以下是摘要：

元数据驱动，即对象关系映射（ORM）

优点：

• 非常抽象-无需更改模型即可切换DB服务器
• 广泛传播-实际上是一个标准
• 减少所需的SQL数量
• 可以将SQL存储在资源文件中
• 性能（通常）是可以接受的
• 元数据驱动的方法
• （数据库）供应商独立性

缺点：

• 隐藏SQL和真正的开发人员意图
• DBA难以审核/更改SQL
• 奇数情况下可能仍需要SQL
• 可以强制使用专有查询语言，例如HQL
• 不适合进行优化（抽象）
• 可能缺乏参照完整性
• 缺乏SQL知识或对数据库中的代码缺乏关注的替代品
• 永远无法达到本机数据库性能（即使接近）
• 模型代码与数据库模型紧密结合

硬编码/封装在DAO层中

优点：

• SQL保留在访问数据的对象（封装）中
• SQL易于编写（开发速度）
• 需要更改时，SQL很容易跟踪
• 简单的解决方案（没有凌乱的架构）

缺点：

• DBA无法检查/更改SQL
• SQL可能成为特定于DB的
• SQL可能变得难以维护

存储过程

优点：

• SQL保存在数据库中（靠近数据）
• SQL由DBMS解析，编译和优化
• SQL对于DBA来说很容易查看/更改
• 减少网络流量
• 增强安全性

缺点：

• SQL与数据库绑定（供应商锁定）
• SQL代码更难维护

外部文件（例如属性或资源文件）

优点

• 可以更改SQL，而无需重建应用程序
• 将SQL逻辑与应用程序业务逻辑解耦
• 所有SQL语句的中央存储库–易于维护
• 更容易理解

缺点：

• SQL代码可能变得难以维护
• 难以检查SQL代码中的（语法）错误

嵌入在SQLJ子句中

优点：

• 更好的语法检查

缺点：

• 与Java的联系太紧密
• 性能低于JDBC
• 缺乏动态查询
• 不太受欢迎