SimpleORM，因为它是直接的，没有魔法。它在Java代码中定义了所有元数据结构，非常灵活。

SimpleORM provides similar functionality to Hibernate by mapping data in a relational database to Java objects in memory. Queries can be specified in terms of Java objects, object identity is aligned with database keys, relationships between objects are maintained and modified objects are automatically flushed to the database with optimistic locks. But unlike Hibernate, SimpleORM uses a very simple object structure and architecture that avoids the need for complex parsing, byte code processing etc. SimpleORM is small and transparent, packaged in two jars of just 79K and 52K in size, with only one small and optional dependency (Slf4j). (Hibernate is over 2400K plus about 2000K of dependent Jars.) This makes SimpleORM easy to understand and so greatly reduces technical risk.

Hibernate，因为它基本上是Java中事实上的标准，并且是创建JPA的驱动力之一。Spring对它有很好的支持，几乎每个Java框架都支持它。最后，GORM是一个非常酷的包装器，它使用Groovy做动态查找器等。

它甚至被移植到。net (NHibernate)，所以你也可以在那里使用它。

SimpleORM，因为它是直接的，没有魔法。它在Java代码中定义了所有元数据结构，非常灵活。

SimpleORM provides similar functionality to Hibernate by mapping data in a relational database to Java objects in memory. Queries can be specified in terms of Java objects, object identity is aligned with database keys, relationships between objects are maintained and modified objects are automatically flushed to the database with optimistic locks. But unlike Hibernate, SimpleORM uses a very simple object structure and architecture that avoids the need for complex parsing, byte code processing etc. SimpleORM is small and transparent, packaged in two jars of just 79K and 52K in size, with only one small and optional dependency (Slf4j). (Hibernate is over 2400K plus about 2000K of dependent Jars.) This makes SimpleORM easy to understand and so greatly reduces technical risk.

许多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))))));

虽然我也担心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的参考实现