JDBC兼容的应用程序应该在哪里存储其SQL语句？为什么？
到目前为止,我设法确定了以下选项:
- 在业务对象中硬编码
- 嵌入在SQLJ子句中
- 封装在单独的类中,例如
数据访问对象
- 元数据驱动(将对象模式与数据模式分离 - 描述元数据中它们之间的映射)
- 外部文件(例如属性或资源文件)
- 存储过程
每个人的"优点"和"缺点"是什么？
SQL代码应该被视为"代码"还是"元数据"？
存储过程是否应仅用于性能优化,还是数据库结构的合法抽象？
性能是决定的关键因素吗？供应商锁定怎么样？
什么是更好的 - 松耦合或紧耦合,为什么？
编辑:谢谢大家的答案 - 这是一个总结:
元数据驱动即对象关系映射(ORM)
优点:
- 非常抽象 - 无需更改模型即可切换数据库服务器
- 广泛传播 - 实际上是一个标准
- 减少所需的SQL数量
- 可以将SQL存储在资源文件中
- 表现(通常)是可以接受的
- 元数据驱动的方法
- (数据库)供应商独立性
缺点:
- 隐藏SQL和真正的开发人员的意图
- DBA很难对SQL进行审核/更改
- 对于奇怪的情况,可能仍然需要SQL
- 可以强制使用专有查询语言,例如HQL
- 不适合优化(抽象)
- 可能缺乏参照完整性
- 替代缺乏SQL知识或缺乏对DB中代码的关注
- 永远不会匹配本机数据库性能(即使它接近)
- 模型代码与数据库模型非常紧密
硬编码/封装在DAO层中
优点:
- SQL保存在访问数据的对象中(封装)
- SQL很容易编写(开发速度)
- 当需要更改时,SQL很容易跟踪
- 简单的解决方案(没有凌乱的架构)
缺点:
- DBA无法查看/更改SQL
- SQL很可能成为特定于数据库的
- SQL可能变得难以维护
存储过程
优点:
- SQL保存在数据库中(靠近数据)
- SQL由DBMS解析,编译和优化
- DBA可以轻松地查看/更改SQL
- 减少网络流量
- 提高安全性
缺点:
- SQL与数据库绑定(供应商锁定)
- SQL代码更难维护
外部文件(例如属性或资源文件)
优点
- 无需重建应用程序即可更改SQL
- 将SQL逻辑与应用程序业务逻辑分离
- 所有SQL语句的中央存储库 - 更易于维护
- 更容易理解
缺点:
- SQL代码可能变得无法维护
- 更难检查SQL代码的(语法)错误
嵌入在SQLJ子句中 …