我们正在规划一个大型企业应用程序。在经历了 J2EE 的痛苦之后，我们正集中精力评估 hibernate。
看起来新的 Java EE API 更简单。我还阅读了一些关于 Hibernate 和 iBatis 的好东西。我们的团队对任何框架都缺乏经验。
我想确定 5 个主要比较点
如果您要管理一个由大约 6 名具有 J2EE 经验的开发人员组成的团队，您会使用哪种 ORM 工具？为什么？
【问题讨论】：
标签： java hibernate orm jakarta-ee ibatis
让我来分析一下。首先，我在Using an ORM or plain SQL? 中写了一些关于这个主题的文章。专门针对您的观点：
学习曲线/易用性
Ibatis 是关于 SQL 的。如果您了解 SQL，则 ibatis 的学习曲线很简单。 Ibatis 在 SQL 之上做了一些事情，例如：
您仍然需要学习，但最大的障碍是 SQL。
另一方面，JPA（包括 Hibernate）试图与 SQL 保持距离，并以对象而不是关系的方式呈现事物。然而，正如 Joel 指出的那样，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 时，您需要花费半天到一天的时间来解决然后计算出设置和调用的组合，让它产生既正确又高效的东西。
您在使用 Ibatis 时不会遇到这种问题，因为您自己编写了 SQL。您可以通过在 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 剪切并粘贴到数据库工具中并运行它。这些年来这对我有用了多少次，我怎么夸大都不为过。
性能/可扩展性
在这里，我认为 ibatis 胜出。它是直接的 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 与 Hibernate）。
【讨论】：
您采用哪种解决方案还取决于您选择（或要求）与 Java EE 规范的合规程度。 JPA 是 Java EE 系统中数据访问的“标准”，因此如果您特别想遵守该标准，则应该使用它（有一些注意事项）。
JPA 是对象关系映射系统的标准化。因此，它不提供实现，它只是定义了一种标准化的方法。 Hibernate Entity Manager 就是这样一种实现。
由于 JPA 是跨多个供应商的标准，并且由于它仍然相当新，它缺少一些在某些用例中有价值的更深奥的功能（例如，用于生成动态 SQL 的 Criteria API）。如果您在需要直接使用 Hibernate 甚至直接使用 JDBC 的情况下使用 JPA 计划。对于这种情况，通用的 DAO 模式非常有用；你可以修改这个：Generic Data Access Objects 以便在 JPA 和 JDBC 中使用。
JPA 有一些困难的限制（特别是如果您习惯了 Hibernate），并且对您强加了某些方法，这些方法对于更习惯于编写直接 JDBC 的开发人员来说是困难的。如果您支持将此作为一种方法，请务必做好功课，了解 ORM 与 JDBC 的优缺点。
如果您使用 JPA，一旦您达到学习曲线，它将在简单开发方面获得回报（特别是如果您正确实施上述 DAO 模式），而且还可以获得查询结果的多层缓存。如果做得好（我知道这是一个很大的“如果”），我已经看到这提供了可观的好处。
最后，如果您有一个灵活性很小的遗留数据模型，那么 Hibernate（和 JPA）会给您带来更多的麻烦，而不是值得。例如：
（添加以回应第一条评论） 如果你有幸重新设计 你的数据库，两个很重要 如果你要成为的考虑因素 使用 ORM：
- 向所有相关表添加版本号列以支持乐观锁定。
- 在数据分析期间，确定不可为空的“alternate key”列 开发人员应将其用于
hashCode()和equals()。不要在这些中使用 PK 列 方法。
【讨论】：
要向列表中添加另一个选项...请查看：
Ebean ORM (http://ebean-orm.github.io)。
它的主要主张是比 JPA 或 Hibernate 更简单、更直观的编程模型。具体来说，它没有 Hibernate Session 或 JPA EntityManager，没有分离/附加对象（没有合并、持久化、刷新），延迟加载正常工作。
...也更易于使用和理解。
您还可以将您自己的 SQL 与 Ebean 一起使用（用于查询、更新、存储过程），并且 IMO 在使用您自己的 SQL 的易用性方面与 Ibatis 相匹配。
如果您希望在 Java SE 中使用 ORM，那么我建议您检查一下。
干杯，罗伯。
【讨论】：
我们目前正在开发一个同时使用 Hibernate 和 ibatis 的项目。 为什么要使用休眠？ 它支持我们的领域模型、关系和继承。我们有一个非常复杂的域模型，hiberante 很好地支持它。 无需担心编写插入、更新等。 Ibatis 仅用于查看。有查询，我们有与查询映射的视图对象（类似于域模型但不是域模型）。 Ibatis 在视图对象中返回您想要的数据，而无需担心从结果集中读取，您必须在 Spring JDBC 中进行管理。 为什么我们不使用 HQl 或 Spring JDBC 呢？ 域是如此复杂，在渲染视图时，我们会进行计算、分组和大量的原生 SQL 函数。我们在查询中完成所有这些，使用动态查询，在 ibatis 中管理条件并获得一个干净的轻量级对象。 如果您必须遍历多个层以在休眠中获取数据，则更有意义 因此，根据您的情况，您可能只想使用一个，也可能两者都不使用。 但毫无疑问，hibernate 不是你不能没有的东西。
【讨论】：
请注意，在重要的多线程应用程序中使用 JPA/Hibernate（可能还有大多数其他 ORM 解决方案）可以很快成为真正的 PITA，因为数据库会话需要仅限于一个线程（会话对象不是线程-安全的）。添加延迟加载以及持久实体最多可以属于一个活动会话的事实......您将陷入困境......
您可能想看看Session management using Hibernate in a *multi-threaded* Swing application（或只搜索“休眠多线程”）。
我的经验法则 (YMMV)：如果应用程序不适合某种请求/响应周期（例如 Web 服务），那么使用其他东西可能会更好。
当然，另一种解决方案是以规避上述框架限制的方式设计应用程序。更改应用程序的设计以便我可以让框架 XYZ 工作，但会留下不好的回味。
不管怎样，只要我的 0.02 美元
【讨论】：
我认为我们应该考虑使用 Java（或 OO）的主要原因。
系统必须灵活并允许不断修改规范（这在现实生活中经常发生）。否则我们应该用 C 编程，因为它要快得多。
我认为 Web 应用程序的最佳堆栈将是 Java EE：JPA - EJB - JSF（具有扩展的持久性上下文对话范围）。
JSF 也比纯 JSP/Servlet 慢，但开发速度更快。
JPA 更难学习，但开发速度更快（你知道：RAD）并且更改不大（容易出错的副本-粘贴）影响。在您最常用的实体中添加一个新列，您将不得不更新 iBatis 中的所有语句...
JPA 并不是在所有情况下都很好，但它涵盖了大多数情况，而且它还让您在不更改任何代码的情况下插入 Native Query 而不是 JPQL。但是如果你发现自己写了太多的 Native Query，你的项目可能更适合 iBatis。
至于性能，如果您了解事物如何转换为 SQL，并且如果您将其用于做他最擅长的事情，如果您将其用于做他不喜欢的事情，那么 JPA 也是高性能的，它会产生太多的查询。没有魔法！您必须了解生成的查询，而不是一味地希望在可能出现一些复杂情况时能够采取简单的方法。
此外，如果开发人员具备 SQL 的所有功能，他们将编写过于复杂的查询来处理业务逻辑，而不是将其放在一个集中的位置，您将在 SQL 中拥有一些业务逻辑，在 EJB 中拥有一些。 JPA 应该用于持久化您的模型，而不是用于业务逻辑。
Criteria Query 也不适合构建安全的复杂动态查询。
【讨论】：
如果您确实有一个未开发项目，您可以使用 hibernate，但请注意学习曲线非常陡峭。
如果您有一个现有的数据库，那么使用 iBatis 会更好，因为一天后您就可以高效工作，再过两天您就可以了解所有相关信息。
您必须考虑的一件事是，休眠条件 API 非常适合创建自定义查询，这取决于您的应用程序，可能是一个很好的论据。
【讨论】：
如果你没有一个好的对象模型，我看不到 Hibernate 的好处。你当然有 ORM 中的“关系”，因为你有一个关系数据库，但“对象”是关键。没有对象，没有 ORM。我认为对象和表之间的 1:1 映射，没有更丰富的对象行为，并不能证明 ORM 是合理的。如果这是您的情况，请坚持使用 JDBC 或 iBatis。
【讨论】：
我建议使用 JPA 并取决于（很大程度上！）您的项目的持续时间/范围，您不妨研究一下 JPA2，因为它提供了 JPA 的一些缺失功能（例如，一个非常好的查询 API )。
【讨论】：
使用休眠模式。您的项目以后肯定会变得更大，并且投资（学习休眠）将以一种或另一种方式获得回报。
【讨论】：
在决定使用哪个 ORM 工具之前，您是否尝试过回答为什么还要使用 ORM 工具？如果您的团队中有了解 SQL 的人员，请参阅坚持使用 JDBC。
【讨论】：