JDBC兼容的应用程序应该在哪里存储其SQL语句，为什么？
到目前为止，我设法找出了这些选项：
>在业务对象中进行硬编码
>嵌入在SQLJ条款中
>封装在单独的类中，例如
Data Access Objects
>元数据驱动(解耦对象
模式从数据模式 –
描述它们之间的映射
元数据)
>外部文件(例如属性或
资源文件)
>存储过程
每个人的“优点”和“缺点”是什么？
SQL代码应该被视为“代码”还是“元数据”？
存储过程只能用于性能优化还是它们是数据库结构的合法抽象？
性能是决定的关键因素吗？ vendor lock-in怎么样？
什么是更好 – 松耦合或紧耦合为什么？
EDITED：谢谢大家的答案 – 这里是一个总结：
元数据驱动，即对象关系映射(ORM)
优点：
>非常抽象 – DB服务器可以
切换而不需要更改
该模型
>广泛 – 几乎是一个标准
>减少所需的SQL量
>可以在资源文件中存储SQL
>性能(通常)可接受
>元数据驱动方法
>(数据库)供应商独立性
缺点：
>隐藏SQL和真正的开发人员
意图
> SQL难以审查/更改
由DBA
> SQL可能仍然需要奇数
病例
>可以强制使用专有
查询语言HQL
>不适合优化
(抽象)
>可以缺少参照完整性
>替代缺乏SQL知识
或缺乏在DB中编码的关心
>从不匹配本机数据库
性能(即使它接近)
>模型代码非常紧密配合
数据库模型
硬编码/封装在DAO层
优点：
> SQL保存在对象中
访问数据(封装)
> SQL很容易写(速度
发展)
> SQL很容易跟踪时
需要更改
>简单的解决方案(没有凌乱
建筑)
缺点：
> DBA无法审核/更改SQL
> SQL很可能成为DB特定的
> SQL可能会变得难以维护
存储过程
优点：
> SQL保存在数据库中(接近
数据)
> SQL被解析，编译和优化
由DBMS
> SQL很容易让DBA审查/更改
>减少网络流量
>增强安全性
缺点：
> SQL绑定到数据库(vendor
锁定)
> SQL代码更难维护
外部文件(例如属性或资源文件)
优点
> SQL可以更改而不需要
重建应用程序
>将SQL逻辑从
应用程序业务逻辑
>所有SQL的中央存储库
语句 – 更容易维护
>更容易理解
缺点：
> SQL代码可能变得不可维护
>很难检查SQL代码
(语法)错误
嵌入在SQLJ子句中
优点：
>更好的语法检查
缺点：
>绑定太接近Java
>低于JDBC的性能
>缺乏动态查询
>不那么受欢迎
