JDBC 和 Hibernate 之间的中间地带？答案

【问题标题】：Middle ground between JDBC and Hibernate?JDBC 和 Hibernate 之间的中间地带？
【发布时间】：2010-02-06 21:18:29
【问题描述】：

我们最近一直在实施 Hibernate 作为 JDBC 的替代品。

我喜欢的是不必不断编写SELECT、UPDATE、INSERT 语句以及相关的PreparedStatement 和ResultSet 代码。

但是，由于所有不同的配置/功能选项和相关的 Hibernate 行为，我发现很难理解和解决随机奇怪的行为 (example A)。我发现缓存、延迟加载等一些功能非常酷，但远远超出了我的需要 - 最终令人困惑。

对于那些只想避免 JDBC 的乏味但又不需要 Hibernate 的所有功能的人来说，是否有更好的中间立场？

【问题讨论】：

可能重复？ stackoverflow.com/questions/299597/simple-jdbc-wrapper
我想说“JDBC 包装器”仍然只是 JDBC。我认为这是一个很好的假设，任何使用 JDBC 的人都使用某种形式的包装器（即：Spring 的JDBCTemplate）。我正在寻找简单抽象的东西，而不是“包装”SQL。

【解决方案1】：

没有完全避免jdbc，但是……我的建议是使用spring框架提供的jbdc支持。你仍然需要编写你的选择、更新和插入，但是 spring 很好地包装了它，所以你通常不需要关心结果集、关闭连接、清理你的代码等等。

查看 spring 文档中的 this chapter 以查看详细信息。您可以创建一个看起来就像 hibernate dao 层一样的整个 dao 层，但内部实现不同。 RowMapper 接口让您可以很好地处理从结果集到对象的转换。总的来说，它提供了一个清晰的关注点分离。

（另一种选择是使用 iBATIS 进行轻量级 O/R 映射，或者至少将您的 sql 查询保留在 Java 代码之外）。

【讨论】：

+1 为 iBATIS。是的，iBATIS 就是您要找的。使用 iBATIS 3 映射器去除代码中的 jdbc 内容。
iBATIS依然没有缓解手工写SQL的问题。
iBATIS 太可怕了。 ORM 框架的问题在于它们易于销售，因为它们更易于使用（例如，开发人员不需要知道 sql），然后你最终不得不处理，正如原始海报所说的那样——奇怪的行为——相关像缓存、会话等。如果你简单地使用基本的 DAO 模式并使用 JDBC 包装器，使用 Spring 中的 JDBCTemplate 之类的东西（正如其他人所说），维护会非常容易。
你也可能不得不调整 ORM 映射配置和/或生成的 SQL 来解决性能问题（例如，当 ORM 框架生成 1000 个查询而不是它可能生成的 1 或 2 个查询时））。然后你带来的下一个开发人员不知道之前的开发人员修复了 ORM 配置，以便它使用 1-2 个查询而不是 1000 个查询带回数据，并将配置更改回其最初的性能不佳状态以解决他们遇到的一些问题在另一段使用相同 ORM 查询的代码中。只需编写 SQL 即可完成
我倾向于同意@Yoni 和@BestPractices。我希望有另一种方法（“中间立场”），但似乎这不存在。

【解决方案2】：

如何使用Hibernate（或TopLink）作为JPA 提供者。 IMO 我发现基于 JPA 注释的 ORM 方法比直接使用 Hibernate 更容易理解/实现 - 而且您始终可以直接使用 Hibernate 进行“困难”的操作。

【讨论】：