Java编程-SQL语句应存储在哪里？
兼容JDBC的应用程序应在哪里存储其SQL语句，为什么？
到目前为止，我设法确定了这些选项：
- 硬编码在业务对象中
- 嵌入在SQLJ子句中
- 封装在单独的类中，例如 数据访问对象
- 驱动元数据（将对象模式与数据模式分离-在元数据中描述它们之间的映射）
- 外部文件（例如属性或资源文件）
- 存储过程
各自的“优点”和“缺点”是什么？
应该将SQL代码视为“代码”还是“元数据”？
存储过程应该仅用于性能优化还是它们是数据库结构的合法抽象？
性能是决定的关键因素吗？什么厂商锁定？
更好的是松耦合还是紧耦合，为什么？
编辑：谢谢大家的答案–以下是摘要：
优点：
- 非常抽象-无需更改模型即可切换DB服务器
- 广泛传播-实际上是一个标准
- 减少所需的SQL数量
- 可以将SQL存储在资源文件中
- 性能（通常）是可以接受的
- 元数据驱动的方法
- （数据库）供应商独立性
缺点：
- 隐藏SQL和真正的开发人员意图
- DBA难以审核/更改SQL
- 奇数情况下可能仍需要SQL
- 可以强制使用专有查询语言，例如HQL
- 不适合进行优化（抽象）
- 可能缺乏参照完整性
- 缺乏SQL知识或对数据库中的代码缺乏关注的替代品
- 永远无法达到本机数据库性能（即使接近）
- 模型代码与数据库模型紧密结合
优点：
- SQL保留在访问数据的对象（封装）中
- SQL易于编写（开发速度）
- 需要更改时，SQL很容易跟踪
- 简单的解决方案（没有凌乱的架构）
缺点：
- DBA无法检查/更改SQL
- SQL可能成为特定于DB的
- SQL可能变得难以维护
优点：
- SQL保存在数据库中（靠近数据）
- SQL由DBMS解析，编译和优化
- SQL对于DBA来说很容易查看/更改
- 减少网络流量
- 增强安全性
缺点：
- SQL与数据库绑定（供应商锁定）
- SQL代码更难维护
优点
- 可以更改SQL，而无需重建应用程序
- 将SQL逻辑与应用程序业务逻辑解耦
- 所有SQL语句的中央存储库–易于维护
- 更容易理解
缺点：
- SQL代码可能变得难以维护
- 难以检查SQL代码中的（语法）错误
优点：
- 更好的语法检查
缺点：
- 与Java的联系太紧密
- 性能低于JDBC
- 缺乏动态查询
- 不太受欢迎
回答：
通常，应用程序在大小和/或可重用性方面的增长越多，对SQL语句的外部化/抽象的需求就越大。
硬编码（作为静态最终常量）是第一步。下一步是存储在文件（properties / xml文件）中。最后一步是驱动元数据（由像Hibernate /
JPA这样的ORM完成）。
硬编码的缺点是您的代码可能变得特定于数据库，并且每次更改都需要重写/重建/重新分发。好处是您可以将它放在1个地方。
存储在文件中的缺点是，随着应用程序的增长，它可能变得无法维护。优点是您无需重写/重建应用程序，除非您需要添加额外的DAO方法。
元数据驱动的缺点是您的模型代码与数据库模型紧密结合。对于数据库模型中的每个更改，您都需要重写/重建/重新分发代码。优势在于它非常抽象，您可以轻松地从数据库服务器切换而无需更改模型（但现在问自己：一家公司从数据库服务器切换的频率是多少？每三年至少一次）是吗？）。
为此，我不会将存储过程称为“好”解决方案。它们的目的完全不同。即使，您的代码将取决于所使用的数据库/配置。
以上是 Java编程-SQL语句应存储在哪里？ 的全部内容， 来源链接： utcz.com/qa/433196.html
