Hibernate，iBatis，Java EE或其他Java ORM工具

Question

我们正在计划大型的企业应用程序。在经历了J2EE的痛苦之后，我们将重点放在评估hibernate状态上。

新的Java EE API看起来更简单。我还阅读了一些有关Hibernate和iBatis的好东西。我们的团队对任何框架都缺乏经验。

我想确定5个主要比较点

• 学习曲线/易用性
• 生产率
• 可维护性/稳定性
• 性能/可伸缩性
• 轻松排除故障

如果您要管理一个由约2名J2EE经验开发人员组成的团队，那么您将使用哪种ORM工具，为什么呢？

Answer 1

专门针对您的观点：

学习曲线/易用性

Ibatis与SQL有关。如果您知道SQL，那么ibatis的学习曲线就微不足道了。Ibatis在SQL之上做一些事情，例如：

• 通过…分组;
• 区分类型；和
• 动态SQL。

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

另一方面，JPA（包括Hibernate）试图与SQL保持距离，并以对象而不是关系的方式呈现事物。正如Joel指出的那样，抽象是泄漏的，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，然后再工作找出设置和调用的组合，以产生出既正确又高效的产品。

Ibatis就是这样，因为您自己编写了SQL。您可以通过在PL / SQL Developer，SQL Server Management
Studio，适用于MySQL的Navicat中运行SQL进行测试。查询正确之后，您要做的就是映射输入和输出。

我还发现JPA-QL比纯SQL更笨拙。您需要单独的工具才能运行JPA-
QL查询以查看结果，这是您需要学习的更多知识。实际上，我发现JPA的整个部分相当笨拙且笨拙，尽管有些人喜欢它。

可维护性/稳定性

Ibatis的危险在于扩散，这意味着您的开发团队可能只在需要它们时就不断添加值对象和查询，而不是寻找重用，而JPA每张表有一个实体，而一旦有了该实体，就够了。命名查询倾向于在该实体上进行，因此很难错过。临时查询仍然可以重复，但是我认为这不是一个潜在的问题。

但是，这是以牺牲刚性为代价的。通常，在应用程序中，您将需要来自不同表的零碎数据。使用SQL，这很容易，因为您可以编写一个查询（或少量查询）来一次获得所有数据并将其放入自定义值对象中。

使用JPA，您可以将该逻辑上移到业务层。实体基本上是全有或全无。现在，这并非完全正确。各种JPA提供程序将允许您部分加载实体等等，但是即使在这里，您也正在谈论相同的离散实体。如果需要4个表中的数据，则需要4个实体，或者需要将所需的数据合并到业务或表示层中的某种自定义值对象中。

我喜欢ibatis的另一件事是，您所有的SQL都是外部的（在XML文件中）。有人会说这是不利条件，但不是我。然后，通过搜索XML文件，可以相对容易地找到表和/或列的用途。将SQL嵌入代码中（或根本没有SQL的情况），很难找到它。您还可以将SQL剪切并粘贴到数据库工具中并运行它。我不能高估这些年来对我有用的次数。

性能/可伸缩性

在这里，我认为ibatis胜出。它是直接的SQL，且成本低。从本质上讲，JPA根本无法管理相同级别的延迟或吞吐量。现在，JPA所做的就是延迟和吞吐量只是很少的问题。但是，高性能系统的确存在，并且将倾向于不利于JPA等重量级解决方案。

加上ibatis，您可以编写一个查询，该查询使用所需的确切列准确返回所需的数据。从根本上说，JPA在返回离散实体时无法击败（甚至匹配）它。

轻松排除故障

我认为这对Ibatis也是一个胜利。就像我上面提到的那样，使用JPA，有时您会花费半天的时间来查询或生成所需的SQL，或者诊断由于实体管理器试图保留非托管对象（可能是批处理的一部分）而导致事务失败的问题您已经做了很多工作的工作，因此找到它可能并非易事。

如果您尝试使用不存在的表或列，那么它们都会失败。

其他标准

现在，您没有提到可移植性是您的要求之一（意味着在数据库供应商之间转移）。值得注意的是，这里JPA具有优势。注释比Hibernate
XML的可移植性差（例如，标准JPA注释与Hibernate的“本机” ID类型不等效），但它们都比ibatis / SQL更可移植。

我还看到JPA /
Hibernate用作可移植DDL的一种形式，这意味着您运行了一个小的Java程序，该程序从JPA配置创建数据库模式。使用ibatis，您需要每个受支持数据库的脚本。

The downside of portability is that JPA is, in some ways, lowest common
denominator, meaning the supported behaviour is largely the common supported
behaviour across a wide range of database vendors. If you want to use Oracle
Analytics in ibatis, no problem. In JPA? Well, that’s a problem.