我们正在规划一个大型企业应用程序。在经历了 J2EE 的痛苦之后，我们将精力集中在评估休眠上。
看起来新的Java EE API更简单。我还读过一些关于Hibernate和iBatis的好东西。我们的团队对任何框架都没有什么经验。
我想确定5个主要的比较点
如果您要管理一个由具有 J2EE 经验的约 6 名开发人员组成的团队，您会使用哪种 ORM 工具，为什么？
让我来谈谈这个问题。首先，我在使用ORM或普通SQL？中写了一些关于这个主题的文章。专门针对您的问题：
学习曲线/易用性
Ibatis是关于SQL的。如果您了解SQL，那么ibatis的学习曲线是微不足道的。Ibatis在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，Navicat for MySQL或其他任何内容中运行SQL来测试它。查询正确后，您所要做的就是映射输入和输出。
另外，我发现JPA-QL比纯SQL更尴尬。您需要单独的工具来运行JPA-QL查询以查看结果，这是您必须学习的更多内容。实际上，我发现JPA的整个部分相当笨拙和笨拙，尽管有些人喜欢它。
可维护性/稳定性
Ibatis的危险在于扩散，这意味着你的开发团队可能会根据需要不断添加价值对象和查询，而不是寻找重用，而JPA每个表都有一个entitty，一旦你拥有了那个实体，就是这样。命名查询倾向于在该实体上进行，因此很难错过。临时查询仍然可以重复，但我认为这不是一个潜在的问题。
然而，这是以僵化为代价的。通常在应用程序中，您将需要来自不同表的位和数据片段。使用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 Analytics，没问题。在JPA中？嗯，这是一个问题。
iBatis和Hibernate之间的一个简单的经验法则是，如果你想要更多的SQL/关系世界观，iBatis更适合;对于更复杂的继承链，以及不太直接查看 SQL，休眠。两者都是广泛使用和坚实的良好框架。所以我认为两者都可能运作良好。也许可以阅读两者的教程，看看一个听起来是否比另一个好，然后只选择一个。
在你列出的事物中，我不认为性能有很大不同 - 瓶颈几乎总是数据库，而不是框架。对于其他事情，我认为不同的开发人员会更喜欢其中一个，即没有普遍接受的优先级（对于iBatis与Hibernate）。
