你更喜欢哪种Java ORM，为什么?

这是一个开放性的问题。我将开始一个新的项目，正在寻找不同的orm与数据库访问集成。

你有喜欢的吗? 有什么你建议不要碰的吗?< / p >

249689 次浏览
小开

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

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

小开

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

SimpleORM提供类似的功能 通过映射到Hibernate的功能 将关系数据库中的数据转换为Java 内存中的对象。查询可以是 用Java对象指定， 对象标识与之对齐 数据库键，之间的关系 维护和修改对象 对象将自动刷新到

但是与Hibernate不同的是，SimpleORM使用了一个 非常简单的对象结构和 避免需要的架构 复杂的解析，字节码处理 等。SimpleORM很小 透明的，包装在两罐 只有79K和52K的尺寸，只有 一个小的可选依赖项 (Slf4j)。(Hibernate超过2400K 加上大约2000K的依赖jar。) 这使得SimpleORM很容易 明白了就大大减少了 技术风险。< / p >
小开

Eclipse的链接，有很多原因，但值得注意的是，我觉得它比其他主流解决方案更少的膨胀(至少少在你面前的膨胀)。

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

小开

我已经停止使用orm了。

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

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

小开

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

小开

当我在编写一个中等大小的JavaSE应用程序时，我有一个非常好的Avaje Ebean经验。

它使用标准JPA注释来定义实体，但公开了一个更简单的API(没有EntityManager或任何附加/分离实体之类的废话)。它还允许您在必要时轻松使用SQL查询或事件纯JDBC调用。

它还为查询提供了一个非常好的流动和类型安全的API。你可以这样写:

List<Person> boys = Ebean.find(Person.class)
.where()
.eq("gender", "M")
.le("age", 18)
.orderBy("firstName")
.findList();
小开

冬眠，因为它:

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

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

  • 您可以在系统中使用对象(如果您的系统设计得很好)。即使使用JDBC，您最终也将创建一些转换层，以便将数据传输到对象。但是我打赌hibernate在翻译方面比任何定制的解决方案都要好。
  • 它不会剥夺你的控制权。你可以在非常小的细节上控制事情，如果API没有一些远程功能-执行一个本机查询，你就有了它。
  • 任何中型或更大的系统都无法承受大量查询(无论是在一个地方还是分散在各处)，如果它的目标是可维护的话
  • 如果性能不重要。Hibernate增加了性能开销，这在某些情况下是不可忽视的。
小开

我建议使用MyBatis。它是JDBC之上的一个薄层，它很容易将对象映射到表，并且仍然使用纯SQL，一切都在您的控制之下。

小开

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

  • SQL是个好东西。在SQL中可以很好地表达许多内容。不需要对SQL进行完全抽象。
  • 关系数据模型是个好东西。它已被证明是过去40年来最好的数据模型。不需要XML数据库或真正面向对象的数据模型。相反，您的公司运行Oracle、MySQL、MSSQL、DB2或任何其他RDBMS的多个实例。
  • SQL有结构和语法。它不应该在JDBC中使用“低级”字符串连接来表示，也不应该在HQL中使用“高级”字符串连接来表示，这两种方式都容易产生语法错误。
  • 在处理主要查询时，变量绑定往往非常复杂。这是应该被抽象出来的东西。
  • 在编写操作数据库数据的Java代码时，POJO非常有用。
  • 手动编写和维护POJO非常痛苦。代码生成是正确的方法。您将拥有编译安全的查询，包括数据类型安全。
  • 首先是数据库。虽然数据库之上的应用程序可能会随着时间的推移而改变，但数据库本身可能会持续更长的时间。
  • 是的，您的遗留数据库中确实有存储过程和用户定义类型(UDT)。您的数据库工具应该支持这一点。

还有许多其他好的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是因为它的应用程序设计总体上很糟糕。

真正的OOD是由类和关系驱动的，ORM给了你不同关系类型和对象的一致映射。 如果你使用ORM工具，最后用ORM框架支持的任何查询语言(包括但不限于Java表达式树、查询方法、OQL等)来编码查询表达式，那么你肯定做错了什么，也就是说，你的类模型很可能没有以它应该的方式支持你的需求。干净的应用程序设计实际上不需要应用程序级别的查询。我重构过许多项目，人们一开始使用ORM框架，就像在代码中嵌入SQL字符串常量一样，最后每个人都惊讶地发现，一旦将类模型与使用模型匹配起来，整个应用程序变得如此简单和可维护。当然，对于像搜索功能之类的东西，你需要一种查询语言，但即使这样，查询也会受到很大的限制，因此创建一个甚至复杂的VIEW并将其映射到一个只读持久化类要比在应用程序的代码中用某种查询语言构建表达式更好维护和观察。VIEW方法还利用了数据库功能，通过物化，可以在性能方面比Java源代码中的任何手写SQL都要好得多。 所以，我不认为一个不平凡的应用程序有任何理由不使用ORM

提交答案