Java - JDBC替代品

Question

这只是理论问题.

我在我的Java应用程序中使用JDBC来使用数据库(选择,插入,更新,删除或其他).我制作"手动"Java类,它将包含来自DB表的数据(attribute = db列).然后我创建查询(ResultSet)并用数据填充这些类.我不确定,如果这是正确的方法.

但我已经阅读了很多关于JDO和其他持久性解决方案的内容.

有人可以根据他们的经验推荐最好用的JDBC替代方案吗？

我还想知道JDO优于JDBC的优点(简单来说).

我已经能够谷歌这些东西,但"第一手"的意见总是最好的.

谢谢

Answer 1

Java中数据库持久性的故事已经很长并且充满了曲折:

• JDBC是每个人最后用来与数据库通信的低级API .但是,如果不使用更高级别的API,则必须自己完成所有繁琐的工作(编写SQL查询,将结果映射到对象等).

• EJB 1.0 CMP Entity Beans是高级API的第一次尝试,已被大型Java EE提供商(BEA,IBM)成功采用,但未被用户采用.实体Bean太复杂,开销太大(理解,性能不佳).失败!

• EJB 2.0 CMP试图通过引入本地接口来降低Entity Beans的一些复杂性,但仍然存在大部分复杂性.EJB 2.0也缺乏可移植性(因为对象关系映射不是规范的一部分,因此部署描述符是专有的).失败!

• 然后是JDO,它是对象持久性的数据存储区域不可知标准(可以与RDBMS,OODBMS,XML,Excel,LDAP一起使用).但是,虽然有几个开源实现,虽然JDO已经被小型独立供应商采用(大多数OODBMS供应商希望JDO用户以后可以从他们的RDBMS数据存储切换到OODBMS - 但这显然从未发生过),但它失败了由大型Java EE玩家和用户采用(因为编织在开发时很痛苦并且吓到一些客户,一个奇怪的查询API,实际上太抽象).因此,虽然标准本身并没有死,但我认为它是失败的.失败!

• 事实上,尽管存在两个标准,但像Toplink,旧播放器或Hibernate这样的专有API 已被用户优先于EJB CMP和JDO用于关系数据库持久性的对象(标准之间的竞争,JDO的定位不明确,早期的失败CMP和糟糕的营销在这方面有责任,我相信)Hibernate实际上已成为该领域的事实标准(它是一个很好的开源框架).成功!

• 然后Sun意识到他们必须简化事情(更普遍的是整个Java EE),他们在Java EE 5中使用JPA,Java Persistence API,它是EJB 3.0的一部分,并且是关系数据库持久性对象的新标准. .JPA统一了EJB 2 CMP,JDO,Hibernate和TopLink API /产品,似乎在EJB CMP和JDO失败的地方取得了成功(易于使用和采用).成功!

总而言之,Java的数据库持久性标准是JPA,应优先于其他专有API(使用Hibernate的JPA实现很好,但使用JPA API),除非ORM不是您需要的.它提供了比JDBC更高级别的API,旨在为您节省大量的手工工作(这是简化的,但这就是想法).

Answer 2

如果你想自己编写SQL,并且不想要一个ORM,你仍然可以从一些隐藏所有繁琐的连接处理的框架中受益(try-catch-finally).最终你会忘记关闭连接......

一个非常容易使用的框架是Spring JdbcTemplate.

Answer 3

我可以推荐Hibernate.它被广泛使用(并且有充分的理由),并且Java Persistence API规范由Hibernate的主要设计者领导,这一事实保证了它将在可预见的未来出现:-)如果可移植性和供应商中立性对您很重要,您可以通过JPA使用它,因此将来您可以轻松切换到另一个JPA实现.

由于缺乏JDO的个人经验,我无法真正比​​较这两者.但是,乍看之下Hibernate(或一般的ORM)的好处似乎与JDO页面上列出的内容几乎相同.对我来说,最重要的一点是:

• 数据库中立性:Hibernate在后台支持多种SQL方言,在数据库之间切换就像在配置中更改单行一样简单
• 性能:默认情况下是延迟获取,还有很多优化工作,你需要用JDBC手动处理它们
• 您可以专注于您的域模型和OO设计而不是较低级别的DB问题(但如果您愿意,您当然可以微调DML和DDL)

(一般来说,ORM工具)的一个潜在缺点是它不适合批处理.如果需要更新表中的100万行,默认情况下ORM的执行速度永远不会与JDBC批处理更新或存储过程一样.Hibernate虽然可以合并存储过程,并且它在某种程度上支持批处理(我还不熟悉它,所以我无法确切地说它是否取决于这方面与JDBC相比的任务 - 但从我的内容来看,判断知道到目前为止,可能是的).因此,如果您的应用需要一些批处理,但主要处理单个实体,Hibernate仍然可以工作.如果它主要是进行批处理,那么JDBC可能是更好的选择.

Answer 4

Hibernate要求您有一个对象模型来映射您的模式.如果您仍然只考虑关系模式和SQL,那么Hibernate可能不适合您.

您必须愿意接受Hibernate将为您生成的SQL.如果您认为使用手动编写的SQL可以做得更好,那么Hibernate可能不适合您.

另一种选择是iBatis.如果JDBC是原始SQL,而Hibernate是ORM,那么iBatis可以被认为是两者之间的东西.它使您可以更好地控制执行的SQL.

Answer 5

JDO构建了JDBC技术.同样,Hibernate仍然需要JDBC.JDBC是Java关于数据库连接的基本规范.

这意味着JDBC将为您提供更好的控制,但它需要更多的管道代码.

JDO提供更高的抽象和更少的管道代码,因为隐藏了很多复杂性.

如果你问这个问题,我猜你不熟悉JDBC.我认为需要对JDBC有基本的了解才能有效地使用JDO,或者使用Hibernate或任何其他更高级的抽象工具.否则,您可能会遇到ORM工具表现出您可能无法理解的行为的情况.

Sun的Java教程在他们的网站上提供了一个不错的介绍材料,可以引导您完成JDBC.http://java.sun.com/docs/books/tutorial/jdbc/.