Hibernate、iBatis、Java EE 或其他 Java ORM 工具 [英] Hibernate, iBatis, Java EE or other Java ORM tool

问题描述

我们正在规划大型企业应用程序.在经历了 J2EE 的痛苦之后，我们正专注于评估 hibernate.

We're in the process of planning a large, enterprise application. We're focusing our efforts on evaluating hibernate after experiencing the pains of J2EE.

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

It looks like the new Java EE API is simpler. I've also read some good things about Hibernate and iBatis. Our team has little experience with any of the frameworks.

我想确定 5 个主要的比较点

There are 5 main comparisong points I'd like to determine

• 学习曲线/易用性
• 生产力
• 可维护性/稳定性
• 性能/可扩展性
• 易于故障排除

如果您要管理一个由约 6 名具有 J2EE 经验的开发人员组成的团队，您会使用哪种 ORM 工具?为什么?

If you were to manage a team of ~6 developers with J2EE experience which ORM tool would you use and why?

推荐答案

让我来看看这个.首先，我在 使用 ORM 或普通 SQL?.专门针对您的观点:

Let me take a crack at this. First of, I've written some on this subject in Using an ORM or plain SQL?. Specifically to address your points:

学习曲线/易用性

Ibatis 是关于 SQL 的.如果您了解 SQL，那么 ibatis 的学习曲线是微不足道的.Ibatis 在 SQL 之上做了一些事情，例如:

Ibatis is about SQL. If you know SQL the learning curve for ibatis is trivial. Ibatis does some things on top of SQL such as:

• 分组依据；
• 有区别的类型；和
• 动态 SQL.

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

that you'll still need to learn but the biggest hurdle is SQL.

另一方面，JPA(包括 Hibernate)试图与 SQL 保持距离，并以对象而不是关系方式呈现事物.然而，正如 Joel 指出的那样，抽象是有漏洞的，JPA 也不例外.要进行 JPA，您仍然需要了解关系模型、SQL、查询的性能调整等.

JPA (which includes Hibernate) on the other hand tries to distance itself from SQL and present things in an object rather than a relational way. As Joel points out however, abstractions are leaky and JPA is no exception. To do JPA you'll still need to know about relational models, SQL, performance tuning of queries and so forth.

Ibatis 只会让您应用您知道或正在学习的 SQL，而 JPA 会要求您知道其他东西:如何配置它(XML 或注释).我的意思是弄清楚外键关系是某种关系(一对一、一对多或多对多)，类型映射等.

Whereas Ibatis will simply having you apply the SQL you know or are learning, JPA will require you to know something else: how to configure it (either XML or annotations). By this I mean figuring out that foreign key relationships are a relationship (one-to-one, one-to-many or many-to-many) of some kind, the type mapping, etc.

如果您了解 SQL，我会说学习 JPA 的障碍实际上更高.如果您不这样做，那么 JPA 的结果更像是一种混合结果，使您可以有效地推迟学习 SQL 一段时间(但不会无限期地推迟).

If you know SQL I would say the barrier to learning JPA is actually higher. If you don't, it's more of a mixed result with JPA allowing you to effectively defer learning SQL for a time (but it doesn't put it off indefinitely).

使用 JPA，一旦您设置了实体及其关系，其他开发人员就可以简单地使用它们，而无需了解有关配置 JPA 的所有知识.这可能是一个优势，但开发人员仍需要了解实体管理器、事务管理、托管与非托管对象等.

With JPA once you setup your entities and their relationships then other developers can simply use them and don't need to learn everything about configuring JPA. This could be an advantage but a developer will still need to know about entity managers, transaction management, managed vs unmanaged objects and so on.

值得注意的是，JPA 也有自己的查询语言(JPA-SQL)，无论您是否了解 SQL，都需要了解它.您会发现 JPA-SQL 不能做 SQL 可以做的事情的情况.

It's worth noting that JPA also has its own query language (JPA-SQL), which you will need to learn whether or not you know SQL. You will find situations where JPA-SQL just can't do things that SQL can.

生产力

这很难判断.就个人而言，我认为我在 ibatis 中的工作效率更高，但我对 SQL 也非常熟悉.有些人会争辩说，他们使用 Hibernate 的效率更高，但这可能是由于(至少部分是)不熟悉 SQL.

This is a hard one to judge. Personally I think I'm more productive in ibatis but I'm also really comfortable with SQL. Some will argue they're way more productive with Hibernate but this is possibly due--at least in part--to unfamiliarity with SQL.

此外，JPA 的生产力具有欺骗性，因为您偶尔会遇到数据模型或查询的问题，当您打开日志记录并观察您的 JPA 提供程序正在生成的 SQL 时，您需要花半天到一天的时间来解决这些问题然后计算出设置和调用的组合，使其产生既正确又高效的东西.

Also the productivity with JPA is deceptive because you will occasionally come across a problem with your data model or queries that takes you a half a day to a day to solve as you turn up logging and watch what SQL your JPA provider is producing and then working out the combination of settings and calls to get it to produce something that's both correct and performant.

您使用 Ibatis 就没有这种问题，因为您自己编写了 SQL.你可以通过在 PL/SQL Developer、SQL Server Management Studio、Navicat for MySQL 或其他任何东西中运行 SQL 来测试它.查询正确后，您要做的就是映射输入和输出.

You just don't have this kind of problem with Ibatis because you've written the SQL yourself. You test it by running the SQL inside PL/SQL Developer, SQL Server Management Studio, Navicat for MySQL or whatever. After the query is right, all you're doing is mapping inputs and outputs.

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

Also I found JPA-QL to be more awkward than pure SQL. You need separate tools to just run a JPA-QL query to see the results and it's something more you have to learn. I actually found this whole part of JPA rather awkward and unwieldy although some people love it.

可维护性/稳定性

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

The danger with Ibatis here is proliferation meaning your dev team may just keep adding value objects and queries as they need them rather than looking for reuse whereas JPA has one entitty per table and once you have that entity, that's it. Named queries tend to go on that entity so are hard to miss. Ad-hoc queries can still be repeated but I think it's less of a potential problem.

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

That comes at the cost of rigidity however. Often in an application you will need bits and pieces of data from different tables. With SQL it's easy because you can write a single query (or a small number of queries) to get all that data in one hit and put it in a custom value object just for that purpose.

使用 JPA，您可以将该逻辑向上移动到您的业务层.实体基本上是全有或全无.严格来说，这不是真的.各种 JPA 提供程序将允许您部分加载实体等等，但即使在那里您谈论的是相同的离散实体.如果您需要来自 4 个表的数据，则您需要 4 个实体，或者您需要将所需的数据组合到业务或表示层中的某种自定义值对象中.

With JPA you are moving up that logic into your business layer. Entities are basically all or nothing. Now that's not strictly true. Various JPA providers will allow you to partially load entities and so forth but even there you're talking about the same discrete entitites. If you need data from 4 tables you either need 4 entities or you need to combine the data you want into some kind of custom value object in the business or presentation layer.

我喜欢 ibatis 的另一件事是您的所有 SQL 都是外部的(在 XML 文件中).有些人会引用这是一个缺点，但不是我.然后，您可以通过搜索 XML 文件相对容易地找到表和/或列的用途.将 SQL 嵌入到代码中(或根本没有 SQL 的地方)可能会更难找到.您还可以将 SQL 剪切并粘贴到数据库工具中并运行它.多年来，这对我有用的次数再多也不为过.

One other thing I like about ibatis is that all your SQL is external (in XML files). Some will cite this is as a disadvantage but not me. You can then find uses of a table and/or column relatively easy by searching your XML files. With SQL embedded in code (or where there is no SQL at all) it can be a lot harder to find. You can also cut and paste SQL into a database tool and run it. I can't overstate enough how many times this has been useful to me over the years.

性能/可扩展性

在这里，我认为 ibatis 胜出.它是直接的 SQL 且成本低.就其性质而言，JPA 根本无法管理相同级别的延迟或吞吐量.现在 JPA 的目标是延迟和吞吐量很少成为问题.然而，高性能系统确实存在，并且会倾向于不喜欢 JPA 等更重量级的解决方案.

Here I think ibatis wins hands down. It's straight SQL and low cost. By its nature JPA simply won't be able to manage the same level of latency or throughput. Now what JPA has going for it is that latency and throughput are only rarely problems. High performance systems however do exist and will tend to disfavour more heavyweight solutions like JPA.

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

Plus with ibatis you can write a query that returns exactly the data you want with the exact columns that you need. Fundamentally there's no way JPA can beat (or even match) that when it's returning discrete entities.

易于故障排除

我认为这也是 Ibatis 的胜利.就像我上面提到的，使用 JPA，您有时会花费半天时间来获取查询或实体生成您想要的 SQL 或诊断事务失败的问题，因为实体管理器试图持久化一个非托管对象(它可能是批处理的一部分)你已经投入了大量工作的工作，所以可能很难找到).

I think this one is a win for Ibatis too. Like I mentioned above, with JPA you will sometimes spend half a day getting a query or entity produce the SQL you want or diagnosing a problem where a transaction fails because the entity manager tried to persist an unmanaged object (which could be part of a batch job where you've committed a lot of work so it might be nontrivial to find).

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

Both of them will fail if you try to use a table or column that doesn't exist, which is good.

其他条件

现在您没有提到可移植性是您的要求之一(意味着在数据库供应商之间移动).值得注意的是，这里JPA有优势.注释的可移植性不如 Hibernate XML(例如，标准 JPA 注释没有对应于 Hibernate 的本机"ID 类型)，但它们都比 ibatis/SQL 更具可移植性.

Now you didn't mention portability as one of your requirements (meaning moving between database vendors). It's worth noting that here JPA has the advantage. The annotations are less portable than, say, Hibernate XML (eg standard JPA annotations don't have an equivalent for Hibernate's "native" ID type) but both of them are more portable than ibatis / SQL.

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

Also I've seen JPA / Hibernate used as a form of portable DDL, meaning you run a small Java program that creates the database schema from JPA configuration. With ibatis you'll need a script for each supported database.

可移植性的缺点是 JPA 在某些方面是最低公分母，这意味着支持的行为在很大程度上是广泛的数据库供应商共同支持的行为.如果你想在ibatis中使用Oracle Analytics，没问题.在 JPA 中?嗯，这是个问题.

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.

这篇关于Hibernate、iBatis、Java EE 或其他 Java ORM 工具的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！