Java - JDBC 替代品

Java - JDBC alternatives

提问by Mike

this is just theoretical question.

这只是理论问题。

I use JDBC with my Java applications for using database (select, insert, update, delete or whatever). I make "manually" Java classes which will contain data from DB tables (attribute = db column). Then I make queries (ResultSet) and fill those classes with data. I am not sure, if this is the right way.

我在 Java 应用程序中使用 JDBC 来使用数据库（选择、插入、更新、删除或其他）。我制作了“手动”Java 类，这些类将包含来自 DB 表（属性 = db 列）的数据。然后我进行查询（ResultSet）并用数据填充这些类。我不确定，这是否是正确的方法。

But I've read lot of about JDO and another persistence solutions.

但是我已经阅读了很多关于 JDO 和另一个持久性解决方案的内容。

Can someone please recommend the best used JDBC alternatives, based on their experience?

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

I would also like to know the advantages of JDO over JDBC (in simple words).

我还想知道 JDO 相对于 JDBC 的优势（简单来说）。

I've been able to google lot of this stuff, but opinions from the "first hand" are always best.

我已经能够在谷歌上搜索很多这些东西，但是“第一手”的意见总是最好的。

Thanks

谢谢

采纳答案by Pascal Thivent

The story of database persistence in Java is already long and full of twists and turns:

Java 中数据库持久化的故事已经很长，而且充满曲折：

• JDBCis the low level API that everybody usesat the end to talk to a database. But without using a higher level API, you have to do all the grunt work yourself (writing SQL queries, mapping results to objects, etc).

• EJB 1.0 CMP Entity Beanswas a first try for a higher level API and has been successfully adopted by the big Java EE providers (BEA, IBM) but not by users. Entity Beans were too complex and had too much overhead (understand, poor performance). FAIL!

• EJB 2.0 CMPtried to reduce some of the complexity of Entity Beans with the introduction of local interfaces, but the majority of the complexity remained. EJB 2.0 also lacked portability (because the object-relational mapping were not part of the spec and the deployment descriptor were thus proprietary). FAIL!

• Then came JDOwhich isa datastore agnostic standard for object persistence (can be used with RDBMS, OODBMS, XML, Excel, LDAP). But, while there are several open-source implementations and while JDO has been adopted by small independent vendors (mostly OODBMS vendors hoping that JDO users would later switch from their RDBMS datastore to an OODBMS - but this obviously never happened), it failed at being adopted by big Java EE players and users (because of weaving which was a pain at development time and scaring some customers, of a weird query API, of being actually too abstract). So, while the standard itself is not dead, I consider it as a failure. FAIL!

• And indeed, despite the existence of two standards, proprietary APIs like Toplink, an old player, or Hibernatehave been preferred by users over EJB CMP and JDO for object to relational database persistence (competition between standards, unclear positioning of JDO, earlier failure of CMP and bad marketing have a part of responsibility in this I believe) and Hibernate actually became the de facto standard in this field (it's a great open source framework). SUCCESS!

• Then Sun realized they had to simplify things (and more generally the whole Java EE) and they did it in Java EE 5 with JPA, the Java Persistence API, which is part of EJB 3.0 and is the new standard for object to relational database persistence. JPA unifies EJB 2 CMP, JDO, Hibernate, and TopLink APIs / products and seems to succeed where EJB CMP and JDO failed (ease of use and adoption). SUCCESS!

• JDBC是每个人最后都用来与数据库对话的低级 API 。但是如果不使用更高级别的 API，您必须自己完成所有繁重的工作（编写 SQL 查询、将结果映射到对象等）。

• EJB 1.0 CMP Entity Beans是对更高级别 API 的首次尝试，并已被大型 Java EE 提供商（BEA、IBM）成功采用，但未被用户采用。实体 Bean 太复杂，开销太大（理解，性能差）。失败！

• EJB 2.0 CMP试图通过引入本地接口来降低实体 Bean 的一些复杂性，但大部分复杂性仍然存在。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 失败的地方取得了成功（易于使用和采用）。成功！

To summarize, Java's standard for database persistenceis JPAand should be preferred over others proprietary APIs (using Hibernate's implementation of JPA is fine but use JPA API) unless an ORM is not what you need. It provides a higher level API than JDBC and is meant to save you a lot of manual work (this is simplified but that's the idea).

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

回答by Péter T?r?k

I can recommend Hibernate. It is widely used (and for good reasons), and the fact that the Java Persistence APIspecification was lead by the main designer of Hibernate guarantees that it will be around for the foreseeable future :-) If portability and vendor neutrality is important to you, you may use it via JPA, so in the future you can easily switch to another JPA implementation.

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

Lacking personal experience with JDO, I can't really compare the two. However, the benefits of Hibernate (or ORM in general) at first sight seem to be pretty much the same as what is listed on the JDO page. To me the most important points are:

由于缺乏 JDO 的个人经验，我无法真正比​​较两者。然而，乍一看，Hibernate（或一般的 ORM）的好处似乎与JDO 页面上列出的几乎相同。对我来说，最重要的几点是：

• DB neutrality: Hibernate supports several SQL dialects in the background, switching between DBs is as easy as changing a single line in your configuration
• performance: lazy fetching by default, and a lot more optimizations going on under the hood, which you woulds need to handle manually with JDBC
• you can focus on your domain model and OO design instead of lower level DB issues (but you can of course fine-tune DML and DDL if you wish so)

• DB 中立性：Hibernate 在后台支持多种 SQL 方言，在 DB 之间切换就像更改配置中的一行一样简单
• 性能：默认情况下延迟获取，以及在引擎盖下进行的更多优化，您需要使用 JDBC 手动处理
• 您可以专注于您的域模型和 OO 设计，而不是较低级别的 DB 问题（但如果您愿意，您当然可以微调 DML 和 DDL）

One potential drawback (of ORM tools in general) is that it is not that suitable for batch processing. If you need to update 1 million rows in your table, ORM by default will never perform as well as a JDBC batch update or a stored procedure. Hibernate can incorporate stored procedures though, and it supports batch processing to some extent (I am not familiar with that yet, so I can't really say whether it is up to the task in this respect compared to JDBC - but judging from what I know so far, probably yes). So if your app requires some batch processing but mostly deals with individual entities, Hibernate can still work. If it is predominantly doing batch processing, maybe JDBC is a better choice.

一个潜在的缺点（通常是 ORM 工具）是它不适合批处理。如果您需要更新表中的 100 万行，默认情况下 ORM 永远不会像 JDBC 批量更新或存储过程那样执行。尽管 Hibernate 可以合并存储过程，并且它在某种程度上支持批处理（我对此还不熟悉，因此与 JDBC 相比，我不能真正说它是否能胜任这方面的任务 - 但从我的情况来看）到目前为止知道，可能是）。因此，如果您的应用程序需要一些批处理但主要处理单个实体，Hibernate 仍然可以工作。如果它主要是做批处理，那么 JDBC 可能是更好的选择。

回答by lsiu

JDO builds off JDBC technology. Similarly, Hibernate still requires JDBC as well. JDBC is Java's fundamental specification on database connectivity.

JDO 建立在 JDBC 技术之上。同样，Hibernate 也仍然需要 JDBC。JDBC 是 Java 关于数据库连接性的基本规范。

This means JDBC will give you greater control but it requires more plumbing code.

这意味着 JDBC 将为您提供更大的控制权，但它需要更多的管道代码。

JDO provide higher abstractions and less plumbing code, because a lot of the complexity is hidden.

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

If you are asking this question, I am guessing you are not familiar with JDBC. I think a basic understanding of JDBC is required in order to use JDO effectively, or Hibernate, or any other higher abstraction tool. Otherwise, you may encounter scenario where ORM tools exhibit behavior you may not understand.

如果你问这个问题，我猜你不熟悉JDBC。我认为为了有效地使用 JDO、Hibernate 或任何其他更高的抽象工具，需要对 JDBC 有基本的了解。否则，您可能会遇到 ORM 工具表现出您可能不理解的行为的场景。

Sun's Java tutorial on their website provide a decent introductory material which walks you through JDBC. http://java.sun.com/docs/books/tutorial/jdbc/.

Sun 在其网站上的 Java 教程提供了一个不错的介绍性材料，可引导您了解 JDBC。http://java.sun.com/docs/books/tutorial/jdbc/。

回答by Bubba88

Hibernate, surely. It's popular, there is even a .NET version.

冬眠，当然。它很受欢迎，甚至还有一个 .NET 版本。

Also, hibernate can be easily integrated with Spring framework.

此外，hibernate 可以很容易地与 Spring 框架集成。

And, it will mostly fit any developer needs.

而且，它主要适合任何开发人员的需求。

回答by rlovtang

A new and exciting alternative is GORM, which is the ORM implementation from Grails. Can now be used stand alone. Under the hood it uses Hibernate, but gives you a nice layer on top with cool dynamic finders etc.

一个新的令人兴奋的替代方案是GORM，它是来自 Grails 的 ORM 实现。现在可以单独使用。在引擎盖下，它使用 Hibernate，但在顶部为您提供了一个很好的层，带有很酷的动态查找器等。

回答by duffymo

Hibernate requires that you have an object model to map your schema to. If you're still thinking only in terms of relational schemas and SQL, perhaps Hibernate is not for you.

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

You have to be willing to accept the SQL that Hibernate will generate for you. If you think you can do better with hand-coded SQL, perhaps Hibernate is not for you.

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

Another alternative is iBatis. If JDBC is raw SQL, and Hibernate is ORM, iBatis can be thought of as something between the two. It gives you more control over the SQL that's executed.

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

回答by Thorbj?rn Ravn Andersen

All these different abstraction layers eventually use JDBC. The whole idea is to automate some of the tedious and error prone work much in the same way that compilers automate a lot of the tedious work in writing programs (resizing a data structure - no problem, just recompile).

所有这些不同的抽象层最终都使用 JDBC。整个想法是自动化一些乏味和容易出错的工作，就像编译器自动化编写程序时的许多乏味工作一样（调整数据结构的大小 - 没问题，只需重新编译）。

Note, however, that in order for these to work there are assumptions that you will need to adhere to. These are usually reasonable and quite easy to work with, especially if you start with the Java side as opposed to have to work with existing database tables.

但是请注意，为了使这些工作正常运行，您需要遵守一些假设。这些通常是合理的并且很容易使用，特别是如果您从 Java 端开始而不是必须使用现有的数据库表。

JDO is the convergence of the various projects in a single Sun standard and the one I would suggest you learn. For implementation, choose the one your favorite IDE suggests in its various wizards.

JDO 是单个 Sun 标准中各种项目的融合，也是我建议您学习的标准。对于实施，请选择您最喜欢的 IDE 在其各种向导中建议的一种。

回答by gmhk

I recommend to use the Hibernate, its really fantastic way of connecting to the database, earlier there were few issues, but later it is more stable. It uses the ORM based mapping, it reduces your time on writing the queries to an extent and it allows to change the databases at a minimum effort. If you require any video based tutorials please let me know I can uplaod in my server and send you the link.

我推荐使用 Hibernate，它连接数据库的方式非常棒，之前几乎没有问题，但后来更稳定了。它使用基于 ORM 的映射，它在一定程度上减少了您编写查询的时间，并且允许以最少的工作量更改数据库。如果您需要任何基于视频的教程，请告诉我我可以在我的服务器上上传并将链接发送给您。

回答by rlovtang

If you want to write SQL yourself, and don't want an ORM, you can still benefit from some frameworks which hides all the tedious connection handling (try-catch-finally). Eventually you will forget to close a connection...

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

One such framework that is quite easy to use is Spring JdbcTemplate.

Spring JdbcTemplate是一种非常易于使用的框架。

回答by Martin Tilsted

There is also torque (http://db.apache.org/torque/) which I personally prefer because it's simpler, and does exactly what I need.

还有我个人更喜欢的扭矩（http://db.apache.org/torque/），因为它更简单，并且完全符合我的需要。

With torque I can define a database with mysql(Well I use Postgresql, but Mysql is supported too) and Torque can then query the database and then generate java classes for each table in the database. With Torque you can then query the database and get back Java objects of the correct type.

使用 Torque 我可以用 mysql 定义一个数据库（我使用 Postgresql，但也支持 Mysql），然后 Torque 可以查询数据库，然后为数据库中的每个表生成 java 类。使用 Torque，您可以查询数据库并取回正确类型的 Java 对象。

It supports where clauses (Either with a Criteria object or you can write the sql yourself) and joins.

它支持 where 子句（使用 Criteria 对象或您可以自己编写 sql）和连接。

It also support foreign keys, so if you got a User table and a House table, where a user can own 0 or more houses, there will be a getHouses() method on the user object which will give you the list of House objects the user own.

它还支持外键，因此如果您有一个 User 表和一个 House 表，其中用户可以拥有 0 个或多个房屋，则用户对象上将有一个 getHouses() 方法，该方法将为您提供 House 对象的列表用户拥有。

To get a first look at the kind of code you can write, take a look at http://db.apache.org/torque/releases/torque-3.3/tutorial/step5.htmlwhich contains examples which show how to load/save/query data with torque. (All the classes used in this example are auto-generated based on the database definition).

要首先了解您可以编写的代码类型，请查看http://db.apache.org/torque/releases/torque-3.3/tutorial/step5.html，其中包含显示如何加载/的示例使用扭矩保存/查询数据。（本示例中使用的所有类都是根据数据库定义自动生成的）。