相关疑难解决方法(0)

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子句中 …

我想将我的应用程序中的一些大型查询外部化到properties\sql\xml文件中.然而,我想知道是否有人有一些关于如何以干净的方式实现这一点的建议.大多数结果建议使用ORM框架,但由于某些数据限制,这不适用.

我看了一下:Java - 在一个外部文件中存储SQL语句,但为一些查询执行这个属性名.1,.2等,每个查询都要长20行看起来不干净.

Spring JDBC模板中似乎没有命名查询支持.通过命名查询,我的意思是在java代码中按名称引用sql语句的工具,并将实际语句保存在某个配置文件中.

在没有开箱即用支持的情况下,我正在研究将sql语句保留在java代码之外的最佳方法.

以下是替代方案:

1. 属性文件
2. xml属性文件
3. spring context xml(依赖注入)

评论？

当我必须连接到数据库时,这是我经常遇到的问题; 如何将SQL与普通的java代码分开？我通常为数据库连接使用单独的类,但是,当每个数据库中有多个数据库和多个表时,总是很难100%这样做

例如,如果我们想将所有java SQL放在一个名为DBConnector.java的类中,那么我们如何针对不同的插入,删除,数据检索等进行一般编码？我认为理想的情况是所有SQL语句应该在同一个类中,并且应该与数据库应用程序范围内的不同类型的相同操作兼容,从而提供与其余代码的逻辑分离.

public void insertData (String db, String table, <Whatever Fields to be Inserted>)
{
  //generic SQL INSERT statement and execution 
}

public ResultSet retrieveData (String db, String table, <Whatever Fields Relevant>) 
{
  //generic retrieval of data
}

有没有办法实现这个目标？或者我们应该只为不同风格的插入,查询等添加功能？

谢谢!