Hibernate、iBATIS、JAVA EE或其他Java ORM工具

让我来试试这个。首先,我在 Using an ORM or plain SQL? . 具体来说,要解决您的问题:

学习曲线/易用性

伊巴斯是关于SQL的。如果你知道SQL,IBatis的学习曲线是微不足道的。iBatis在SQL之上执行一些操作,例如:

• 分组;
• 有区别的类型;以及
• 动态SQL

您仍然需要学习,但最大的障碍是SQL。

另一方面,JPA(包括Hibernate)试图与SQL保持距离,并以对象而不是关系的方式呈现事物。但乔尔指出, abstractions are leaky JPA也不例外。要实现JPA,您仍然需要了解关系模型、SQL、查询的性能调优等等。

虽然iBATIS只是让您应用您知道或正在学习的SQL,但JPA将要求您了解其他一些东西:如何配置它(XML或注释)。我的意思是指出,外键关系是某种类型的关系(一对一、一对多或多对多)、类型映射等。

如果你知道SQL,我会说学习JPA的障碍实际上更高。如果您不这样做,它更多的是一个与JPA混合的结果,它允许您有效地将学习SQL推迟一段时间(但它不会无限期地推迟)。

有了JPA,一旦你设置了你的实体和它们的关系,其他开发人员就可以简单地使用它们,而不需要学习所有关于配置JPA的知识。这可能是一个优势,但开发人员仍然需要了解实体管理器、事务管理、托管对象和非托管对象等。

值得注意的是,JPA也有自己的查询语言(JPA-SQL),您需要了解您是否了解SQL。您将发现JPA-SQL不能做SQL能做的事情。

生产力

这很难判断。我个人认为我在iBatis中的效率更高,但我也非常熟悉SQL。有些人会争辩说他们对Hibernate的效率要高得多,但这可能是因为(至少在一定程度上)不熟悉SQL。

另外,JPA的工作效率也是有欺骗性的,因为您偶尔会遇到数据模型或查询的问题,这些问题需要您半天到一天的时间来解决,因为您打开日志,查看JPA提供程序正在生成的SQL,然后计算出设置和调用的组合,以使它生成同时具有正确和执行。

你对伊巴提斯没有这种问题,因为你自己写了SQL。您可以通过在pl/sql开发人员、SQL Server Management Studio、Navicat for MySQL或其他任何工具中运行SQL来测试它。在查询正确之后,您所要做的就是映射输入和输出。

另外,我发现JPA-QL比纯SQL更笨拙。您需要单独的工具来运行JPA-QL查询来查看结果,这是您需要学习的更多内容。事实上,我发现JPA的这一部分相当笨拙和笨拙,尽管有些人喜欢它。

可维护性/稳定性

iBATIS的危险在于扩散,这意味着您的开发团队可能只是根据需要不断地添加值对象和查询,而不是寻找重用,而JPA每个表只有一个实体,一旦您拥有了该实体,就是这样。命名查询往往会出现在该实体上,因此很难错过。临时查询仍然可以重复,但我认为这不是一个潜在的问题。

然而,这是以刚性为代价的。通常在应用程序中,您需要来自不同表的数据位和数据块。使用SQL很容易,因为您可以编写一个查询(或少量查询),以便在一次命中中获取所有数据,并将其放入一个自定义值对象中。

使用JPA,您将向上移动该逻辑到您的业务层。实体基本上都是或什么都不是。但事实并非如此。各种JPA提供程序将允许您部分加载实体等等,但即使在那里,您也在谈论相同的离散实体。如果需要来自4个表的数据,您要么需要4个实体,要么需要将所需的数据组合成业务层或表示层中的某种自定义值对象。

我喜欢iBATIS的另一件事是,您的所有SQL都是外部的(在XML文件中)。有人会说这是一个缺点,但我没有。然后,通过搜索XML文件,您可以相对容易地找到表和/或列的用途。如果代码中嵌入了SQL(或者根本没有SQL),则很难找到它。您还可以将SQL剪切并粘贴到数据库工具中,然后运行它。我不能夸大这些年来这对我有用的次数。

性能/可扩展性

在这里我认为伊巴提斯赢了。它是直接SQL,成本低。从本质上讲,JPA根本无法管理相同级别的延迟或吞吐量。现在JPA的目标是延迟和吞吐量很少出现问题。然而,高性能系统确实存在,并且倾向于不支持像JPA这样的更重的解决方案。

另外,使用iBATIS,您还可以编写一个查询,用您需要的确切列精确返回所需的数据。从根本上讲,当JPA返回离散实体时,它是无法击败(甚至匹配)的。

易于故障排除

我认为这也是伊巴斯的胜利。就像我上面提到的,使用JPA,您有时会花费半天时间来获取一个查询或实体生成您想要的SQL,或者诊断一个事务失败的问题,因为实体管理器试图持久化一个非托管对象(这可能是批处理作业的一部分,在该作业中,您已提交了大量工作,因此查找起来可能很重要)。

如果您尝试使用不存在的表或列,这两种方法都将失败,这是好事。

其他标准

现在,您没有提到可移植性是您的需求之一(意味着在数据库供应商之间移动)。值得注意的是,JPA在这里有优势。这些注释的可移植性不如Hibernate XML(例如,标准JPA注释没有与Hibernate的“本机”ID类型等效的注释),但它们都比IBatis/SQL更易于移植。

我也看到JPA/Hibernate作为一种便携DDL的形式,这意味着您运行一个Java小程序,它从JPA配置创建数据库模式。使用iBATIS,您需要为每个受支持的数据库编写一个脚本。

可移植性的缺点是,在某些方面,JPA是最低的公分母,这意味着受支持的行为在很大程度上是广泛的数据库供应商所支持的常见行为。如果您想在iBATIS中使用Oracle分析,没问题。在JPA?嗯,这是个问题。

IBatis和Hibernate之间的一个简单经验法则是,如果您想要更多的SQL/关系世界视图,IBatis更适合;对于更复杂的继承链,而不是SQL的直接视图,IBatis更适合Hibernate。 两者都是广泛使用和坚实良好的框架。所以我认为这两种方法都可能很有效。也许读一下这两者的教程,看看其中一个是否比另一个更好,然后选择一个。

在您列出的事情中,我不认为性能有很大的不同——瓶颈几乎总是数据库,而不是框架。对于其他事情,我认为不同的开发人员会选择其中一个或另一个,即没有普遍接受的优先权(对于iBatis和Hibernate)。

您所采用的解决方案也取决于您如何选择(或需要)与JavaEE规范。JPA是JavaEE系统中数据访问的“标准”,因此,如果您坚持遵循该标准,就应该使用它(有一些警告)。

JPA是对象关系映射系统的标准化。因此,它不提供实现,它只是定义了一个标准化的方法。Hibernate实体管理器就是这样一个实现。

由于JPA是多个供应商的标准,而且它仍然是相当新的,因此它缺少一些在某些用例(例如,用于生成动态SQL的标准API)中有价值的更深奥的功能。如果你按照JPA计划来处理那些需要直接使用Hibernate甚至直接使用JDBC的情况。对于这种情况,一般的DAO模式非常有用;您可以修改这个模式: Generic Data Access Objects 在jpa&jdbc中使用非常容易。

JPA有一些困难的限制(特别是当你习惯了休眠的时候),并且对那些更习惯于直接编写JDBC的开发人员来说,它对你施加了一些困难的方法。如果您支持将此作为一种方法,那么一定要做好关于ORM与JDBC的优缺点的家庭作业。

如果您使用JPA,一旦您达到了学习曲线,它将在简单的开发(特别是如果您正确地实现了上面提到的DAO模式)方面得到回报,而且在获取查询结果的多层缓存方面也会得到回报。如果做得好(我知道是一个很大的“如果”),我已经看到这会带来很多好处。

最后,如果您有一个灵活性很低的遗留数据模型,Hibernate(和JPA)会给您带来比可能值更多的麻烦。例如:

• 如果数据库没有候选主键(对于有效的hashcode&equals实现),则需要对哪些列唯一地定义行进行预先分析——可能简单,也可能复杂,具体取决于架构的复杂性;
• 如果无法添加版本或时间戳列,则会失去Hibernate进行乐观锁定的能力,并最终在更新之前查询。

(为响应第一条评论而添加) 如果你有幸重新设计 你的数据库,两个非常重要的 如果你打算 使用ORM:

• 向所有相关表中添加版本号列以支持乐观锁定。
• 在数据分析过程中,决定不可为空” alternate key “列” 开发人员应该用于 hashCode() 和; equals() . 不要在其中使用pk列 方法。

要向列表中添加另一个选项…看一看:

EBON ORM http://ebean-orm.github.io )

它的主要主张是比JPA或Hibernate更简单、更直观的编程模型。具体来说,它没有Hibernate会话或JPA EntityManager,没有分离/附加的对象(没有合并、持久、刷新),延迟加载才有效。

…也就是说,使用和理解要简单得多。

您还可以将自己的SQL与EBean(用于查询、更新、存储过程)和IMO一起使用,它与iBATIS相匹配,以便于使用自己的SQL。

如果您想在Java SE中使用ORM,那么我建议您检查一下。

• LGPL许可证
• 使用JPA注释进行映射(@entity、@onetomany等)
• 无会话API(无合并、持久、刷新…save()和delete()代替)
• “部分对象”支持
• 大型查询支持(每个对象图形持久性上下文)
• 后台查询
• 很好地支持批处理
• 自动查询调整(通过“自动蚀刻”)。

干杯,Rob。

我们目前正在研究一个同时使用Hibernate和Ibatis的项目。 为什么使用休眠? 它支持我们的域模型、关系和继承。我们有一个非常复杂的领域模型,Hiberant非常支持它。 无需担心写入插入、更新等。 iBATIS仅用于查看。有查询,我们有视图对象(类似于域模型,但不是域模型),这些对象是用查询映射的。ibatis返回视图obejct中的数据,而不必担心从结果集读取数据,这在SpringJDBC中是必须管理的。 为什么我们不使用HQL或SpringJDBC? 域是如此复杂,在呈现视图时,我们会进行计算、分组和大量本地SQL函数。我们在查询中完成所有这些工作,使用动态查询,在iBATIS中管理条件,并得到一个干净的轻量级对象。 如果您必须遍历多个层才能在休眠中获取数据,那么这就更有意义了。 因此,根据您的情况,您可能只想使用一个,两个或可能都不使用。 但绝对的,冬眠不是你不能没有的。

请注意,在非平凡的多线程应用程序中使用JPA/Hibernate(可能还有大多数其他ORM解决方案)可以很快成为真正的PITA,因为数据库会话需要仅限于一个线程(会话对象不是线程安全的)。添加懒惰的加载和持久实体最多只能属于一个活动会话的事实…而您正处于一个地狱般的旅程中…

你可能想看看 Session management using Hibernate in a *multi-threaded* Swing application (或者只搜索“休眠多线程”)。

我的经验法则(YMMV):如果应用程序本身不适合某种类型的请求/响应周期(例如WebService),那么您最好使用其他的东西。

当然,另一种解决方案是以绕过上述框架限制的方式设计应用程序。但是,更改应用程序的设计以便让框架XYZ工作会留下不好的余味。

不管怎样,只要我的0.02美元

我认为我们应该考虑我们使用Java(或OO)的主要原因。

系统必须是灵活的,并且允许不断修改规范(这在现实生活中经常发生)。否则我们应该用C语言编程,因为它要快得多。

我认为Web应用程序的最佳堆栈将是JavaEE:JPA-EJB-JSF(具有扩展的持久上下文会话范围)。

JSF也比纯JSP/servlet慢,但开发速度更快。

JPA很难学习,但是它的开发速度更快(您知道:rad),并且更改不会产生很大的(容易出错的复制粘贴)影响。在最常用的实体中添加一个新列,您将不得不更新iBATIS中的所有语句…

JPA并不能很好地处理所有的情况,但它覆盖了大多数情况,而且它还允许您在不更改任何代码的情况下插入本机查询而不是JPQL。但是如果你发现自己写了太多的本地查询,你的项目可能更适合iBATIS。

至于性能,如果你理解事物是如何转换成SQL的,如果你把它放在他最擅长的地方,如果你把它放在对他来说不舒服的地方,它也会产生太多的查询。没有魔法!您必须了解生成的查询,而不是盲目地希望在某些复杂的情况出现时能够采取简单的方法。

另外,如果开发人员拥有SQL的所有功能,他们将编写过于复杂的查询来处理业务逻辑,而不是将其集中在一个地方,那么您将拥有一些SQL中的业务逻辑,一些EJB中的业务逻辑。JPA应该用于持久化您的模型,而不是用于业务逻辑。

条件查询也与生成安全的NoMatterhowComplex动态查询不匹配。

如果你确实有一个绿地项目,你可以使用Hibernate,但是要注意学习曲线是相当陡峭的。

如果您有一个现有的数据库,那么您对iBATIS的了解就更好了,因为在一天之后,您就可以提高工作效率,在两天之后,您就可以完全了解它了。

您必须考虑的一件事是,Hibernate标准API非常适合创建自定义查询,这可能是一个很好的理由,具体取决于您的应用程序。

如果你没有一个好的对象模型,我看不到Hibernate的好处。因为您有一个关系数据库,所以您在ORM中当然有“关系”这个词,但是“对象”是关键。没有对象,没有ORM。我认为,如果没有更丰富的对象行为,对象和表之间的1:1映射就不能证明ORM是正确的。如果这是你的情况,坚持使用JDBC或IBatis。

我建议和JPA一起去,而且要看情况而定。在项目的持续时间/范围上,您不妨研究一下JPA2,因为它提供了JPA中一些缺失的特性(例如,一个非常好的查询API)。

去冬眠吧。你的项目以后肯定会变得更大,投资(学习冬眠)将以某种方式获得回报。

在决定使用哪个ORM工具之前,您是否尝试过回答为什么使用ORM工具?如果您的团队中有了解SQL的人,请参见StickToJDBC。