Java JDBC和Hibernate之间的中间地带？

我们最近一直在实现Hibernate以替代JDBC

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

然而，由于所有不同的配置/功能选项以及相关的Hibernate行为，我发现很难理解和解决随机奇怪的行为。我发现缓存、延迟加载等一些特性非常酷，但远远超出了我的需要——最终会让人困惑

---

对于那些只想避免JDBC的繁琐而不需要Hibernate所有功能的人来说，有没有更好的折衷办法呢？

不是完全避免JDBC，而是。。。我的建议是使用spring框架提供的jbdc支持。您仍然需要编写select、update和INSERT，但是spring很好地包装了它，所以您通常不关心结果集、关闭连接、清理代码等等

从spring文档中查看详细信息。您可以创建一个与hibernate dao层类似的完整dao层，但是内部实现是不同的。RowMapper接口允许您非常好地处理从结果集到对象的转换。总的来说，它提供了一个清晰的关注点分离

---

另一种选择是用于轻量级O/R映射，或者至少将sql查询保持在Java代码之外。

使用或作为提供者如何。我发现基于JPA注释的ORM方法比直接使用Hibernate更容易理解/实现，而且您可以随时直接使用Hibernate做“困难”的事情。

可能重复吗？我认为JDBC包装器仍然只是JDBC。我认为这是一个很好的假设，任何使用JDBC的人都会使用某种形式的包装器，即Spring的JDBC模板。我正在寻找一些简单的抽象，而不是包装的SQL。+1为iBATIS。是的，iBATIS就是你要找的。使用iBATIS3映射器来摆脱代码中的jdbc内容。iBATIS仍然不能缓解手工编写SQL的问题。iBATIS很可怕。ORM框架的问题在于，它们很容易销售，因为更易于使用。例如，开发人员不需要了解sql，然后你就不得不处理，正如最初的海报所说，奇怪的行为与缓存等相关，会话等。如果您只需使用基本DAO模式并使用JDBC包装器（如其他人所说，使用Spring中的JDBCTemplate之类的工具），那么维护就非常容易。您还可能不得不调整ORM映射配置和/或生成SQL，以解决性能问题，例如，当ORM框架生成1000个查询，而不是它可能生成的1或2个查询。然后你带来的下一个开发人员不知道前一个开发人员修复了ORM配置，因此它使用1-2个查询而不是1000个查询返回数据，并将配置更改回其原始的执行不良状态，以修复他们在使用相同ORM查询的另一段代码中遇到的一些问题。只要编写SQL，就可以完成，我倾向于同意@Yoni和@BestPractices。我希望有另一种方法，即中间立场，但这似乎并不存在。