java db保存在哪里_Java编程 – SQL语句应该存储在哪里？

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的性能

>缺乏动态查询

>不那么受欢迎