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

问题描述

我们正在规划一个大型的企业应用程序。在遇到J2EE的痛苦之后，我们将重点放在评估hibernate上。

看起来新的Java EE API更简单。我也读过关于Hibernate和iBatis的一些好消息。我们的团队对任何框架都没有经验。

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

学习曲线/易用性

效率

可维护性/稳定性
性能/可扩展性

如果您要管理团队大约6位具有J2EE经验的开发人员将使用哪种ORM工具？为什么？

解决方案

让我对此加以解释。首先，我在使用ORM或普通的SQL？。特别为了解决您的观点：

学习曲线/易用性 b b

是关于SQL的。如果你知道SQL，ibatis的学习曲线是微不足道的。 Ibatis在SQL之上做了一些事情，比如：

• group by;


• 歧视类型;和


• 动态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剪切并粘贴到数据库工具中并运行它。我无法夸大这些年来这对我有多大用处。

性能/可伸缩性

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

再加上ibatis，你可以编写一个查询，准确返回你想要的数据你需要的列。从根本上说，当JPA返回离散实体时，它无法击败（或甚至匹配）。

简易故障排除

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

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

其他标准

不提可移植性作为您的一项要求（意味着在数据库供应商之间移动）。值得注意的是，JPA在这里有优势。注释的可移植性不如Hibernate XML（例如，标准的JPA注释没有Hibernate的nativeID类型），但它们都比ibatis / SQL更具可移植性。

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

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

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.

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.

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

• Learning Curve/Ease of Use
• Productivity
• Maintainability/Stability
• Performance/Scalability
• Ease of Troubleshooting

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

解决方案

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:

Learning Curve/Ease of Use

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:

• group by;
• discriminated types; and
• dynamic SQL.

that you'll still need to learn but the biggest hurdle is 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.

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.

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).

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.

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.

Productivity

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.

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.

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.

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.

Maintainability/Stability

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.

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.

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.

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.

Performance/Scalability

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.

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.

Ease of Troubleshooting

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.

Other criteria

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.

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.

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屋！