许多ORM都很棒，您需要知道为什么要在JDBC之上添加抽象。我可以向你推荐http://www.jooq.org(免责声明:我是jOOQ的创建者，所以这个答案是有偏见的)。jOOQ包含以下范例:

SQL is a good thing. Many things can be expressed quite nicely in SQL. There is no need for complete abstraction of SQL. The relational data model is a good thing. It has proven the best data model for the last 40 years. There is no need for XML databases or truly object oriented data models. Instead, your company runs several instances of Oracle, MySQL, MSSQL, DB2 or any other RDBMS. SQL has a structure and syntax. It should not be expressed using "low-level" String concatenation in JDBC - or "high-level" String concatenation in HQL - both of which are prone to hold syntax errors. Variable binding tends to be very complex when dealing with major queries. THAT is something that should be abstracted. POJO's are great when writing Java code manipulating database data. POJO's are a pain to write and maintain manually. Code generation is the way to go. You will have compile-safe queries including datatype-safety. The database comes first. While the application on top of your database may change over time, the database itself is probably going to last longer. Yes, you do have stored procedures and user defined types (UDT's) in your legacy database. Your database-tool should support that.

还有许多其他好的ORM。特别是Hibernate或iBATIS有一个很棒的社区。但是如果您正在寻找一个直观的、简单的方法，我会建议您试试jOOQ。你会喜欢的!: -)

看看下面的SQL示例:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

以及它如何在jOOQ中表示:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

我已经停止使用orm了。

原因并不是这个概念有什么大缺陷。Hibernate工作得很好。相反，我发现查询的开销很低，我可以将大量复杂的逻辑放入大型SQL查询中，并将大量处理转移到数据库中。

因此，请考虑只使用JDBC包。

虽然我也担心Java会取代自由形式的SQL查询，但我确实认为人们批评ORM是因为它的应用程序设计总体上很糟糕。

True OOD is driven by classes and relationships, and ORM gives you consistent mapping of different relationship types and objects. If you use an ORM tool and end up coding query expressions in whatever query language the ORM framework supports (including, but not limited to Java expression trees, query methods, OQL etc.), you are definitely doing something wrong, i.e. your class model most likely doesn't support your requirements in the way it should. A clean application design doesn't really need queries on the application level. I've been refactoring many projects people started out using an ORM framework in the same way as they were used to embed SQL string constants in their code, and in the end everyone was suprised about how simple and maintainable the whole application gets once you match up your class model with the usage model. Granted, for things like search functionality etc. you need a query language, but even then queries are so much constrained that creating an even complex VIEW and mapping that to a read-only persistent class is much nicer to maintain and look at than building expressions in some query language in the code of your application. The VIEW approach also leverages database capabilities and, via materialization, can be much better performance-wise than any hand-written SQL in your Java source. So, I don't see any reason for a non-trivial application NOT to use ORM.

Eclipse Link，有很多原因，但值得注意的是，我觉得它比其他主流解决方案的膨胀要小(至少不那么让人头疼)。

哦，Eclipse Link已被选为JPA 2.0的参考实现

冬眠，因为它:

是稳定的-存在了这么多年，它没有任何大的问题 规定了ORM领域的标准 实现标准(JPA)，并对其进行口述。 网上有很多关于它的信息。有许多教程，常见问题的解决方案等 功能强大—您可以将非常复杂的对象模型转换为关系模型。 它支持任何主要和中型RDBMS 一旦你学会了它，就很容易使用

关于为什么(以及何时)使用ORM的几点:

you work with objects in your system (if your system has been designed well). Even if using JDBC, you will end up making some translation layer, so that you transfer your data to your objects. But my bets are that hibernate is better at translation than any custom-made solution. it doesn't deprive you of control. You can control things in very small details, and if the API doesn't have some remote feature - execute a native query and you have it. any medium-sized or bigger system can't afford having one ton of queries (be it at one place or scattered across), if it aims to be maintainable if performance isn't critical. Hibernate adds performance overhead, which in some cases can't be ignored.

没有，因为ORM占用了太多的控制权，而且好处很小。当您必须调试使用ORM导致的异常时，所节省的时间很容易被浪费掉。此外，orm不鼓励开发人员学习SQL和关系数据库的工作方式，并将其用于自己的利益。