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

EN

让我对此做一个解释。首先，我在使用ORM或纯SQL中写了一些关于这个主题的内容？。特别要说明你的观点：

学习曲线/易用性

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然后工作将设置和调用结合起来，让它产生正确和高性能的东西。

因为你已经自己编写了SQL，所以你不会对Ibatis有这样的问题。您可以通过在PL / SQL Developer，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返回离散实体时，它无法击败（甚至无法匹配）。

易于排除故障

我认为这也是Ibatis的一场胜利。就像我上面提到的那样，对于JPA，有时你会花费半天的时间来获取查询或实体生成所需的SQL，或者诊断事务失败的问题，因为实体管理器试图持久化一个非托管对象（可能是批处理的一部分在你做了很多工作的地方工作，因此可能不太重要）。

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

其他标准

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

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

可移植性的缺点在于JPA在某些方面是最低的共同标准，这意味着支持的行为在很大程度上是各种数据库供应商共同支持的行为。如果您想在ibatis中使用Oracle Analytics，则没有问题。在JPA中？那么，这是一个问题。

iBatis和Hibernate之间简单的经验法则是，如果你想要更多的SQL /关系视图的世界，iBatis更适合; 并为更复杂的继承链，而不直接查看SQL，Hibernate。两者都是广泛使用和坚实的良好框架。所以我认为两者都可能运作良好。也许可以阅读两篇教程，看看一个听起来比另一个更好，然后选择一个。

你列出的东西，我不认为性能是非常不同的 - 瓶颈几乎总是数据库，而不是框架。对于其他事情，我认为不同的开发人员会更喜欢其中一种，即没有普遍接受的优先级（针对iBatis vs Hibernate）。