Hibernate、iBatis、Java EE 或其他 Java ORM 工具
我们正在规划一个大型企业应用程序。 在经历了 J2EE 的痛苦之后，我们将重点放在评估 hibernate 上。
看起来新的 Java EE API 更简单。 我还阅读了一些有关 Hibernate 和 iBatis 的好文章。 我们的团队对任何框架都缺乏经验。
我想确定 5 个主要比较点
- 学习曲线/易用性
- 生产力
- 可维护性/稳定性
- 性能/可扩展性
- 故障排除的简易性
如果您要管理一个由约 6 名具有 J2EE 经验的开发人员组成的团队，您会使用哪种 ORM 工具以及原因？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
让我来尝试一下。 首先，我在 使用 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 每个表都有一个实体，一旦您拥有了该实体实体，就是这样。 命名查询往往会在该实体上进行，因此很难错过。 临时查询仍然可以重复，但我认为这不是一个潜在的问题。
然而，这是以僵化为代价的。 通常在应用程序中，您需要来自不同表的少量数据。 使用 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？ 嗯，这是一个问题。
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:
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.
iBatis 和 Hibernate 之间的一个简单的经验法则是，如果您想要更多的 SQL/关系视图，那么 iBatis 更适合； 而对于更复杂的继承链，不太直接查看SQL，Hibernate。
两者都是广泛使用且可靠的良好框架。 所以我认为两者都可能效果很好。 也许阅读两者的教程，看看其中一个听起来是否比另一个更好，然后选择一个。
在你列出的事情中，我不认为性能有很大不同——瓶颈几乎总是数据库，而不是框架。 对于其他事情，我认为不同的开发人员会更喜欢其中之一，即没有普遍接受的优先级（对于 iBatis 与 Hibernate）。
A simplistic rule of thumb between iBatis and Hibernate is that if you want more SQL/relational view of the world, iBatis is better fit; and for more complex inheritance chain, and less direct view to SQL, Hibernate.
Both are widely used and solid good frameworks. So I think both would probably work well. Perhaps read a tutorial for both, see if one sounds better than the other, and just pick one.
Of things you list, I don't think performance is very different -- bottleneck will almost invariably be the database, not framework. For other things I think different developers would prefer one or the other, i.e. there's no commonly accepted priority (for iBatis vs Hibernate).
您选择哪种解决方案还取决于您选择（或要求）与 Java EE 规范的合规程度。 JPA 是 Java EE 系统中数据访问的“标准”，因此如果您特别想遵守它，则应该使用它（有一些注意事项）。
JPA 是对象关系映射系统的标准化。 因此，它不提供实现，它只是定义了一种标准化方法。 Hibernate Entity Manager 就是这样的一种实现。
由于 JPA 是跨多个供应商的标准，并且它仍然相当新，因此它缺乏一些在某些用例中有价值的深奥功能（例如，用于生成动态 SQL 的 Criteria API）。 如果您使用 JPA，请计划需要直接使用 Hibernate，甚至直接使用 JDBC 的情况。 对于这种情况，通用 DAO 模式非常有用； 你可以修改这个：通用数据访问对象用于JPA和 JDBC 相当容易。
JPA 有一些困难的限制（特别是如果您习惯了 Hibernate），并且强加了某些方法，这对于更习惯于直接编写 JDBC 的开发人员来说是困难的。 如果您支持这种方法，请务必做好功课，了解 ORM 与 JDBC 的优缺点。
如果您使用 JPA，一旦您达到了学习曲线，它将在简单开发方面获得回报（特别是如果您正确实现上述 DAO 模式），而且还会在获得查询结果的多层缓存方面获得回报。 如果做得好（我知道这是一个很大的“如果”），我已经看到这会带来可观的好处。
最后，如果您有一个缺乏灵活性的遗留数据模型，Hibernate（和 JPA）会给您带来更多的麻烦，而不是值得的。 例如：
Which solution you go with also is dependent on how compliant you choose (or are required) to be with the Java EE spec. JPA is "the standard" for data access in Java EE systems, so if you're particular about adhering to that, you should use it (with some caveats).
JPA is a standardization of object-relational mapping systems. As such, it does not provide an implementation, it simply defines a standardized approach. Hibernate Entity Manager is one such implementation.
Since JPA is a standard across multiple vendors and since it is still fairly new, it lacks some more esoteric functionality that is valuable in some use cases (for example, a Criteria API for generating dynamic SQL). If you go with JPA plan on situations where you'll nee to use Hibernate directly, or even JDBC directly. For situations such as this, a generic DAO pattern is very useful; you can modify this one: Generic Data Access Objects for use in JPA & JDBC quite easily.
JPA has some difficult restrictions (particularly if you're used to Hibernate), and imposes certain approaches on you that are difficult for developers who are more used to writing straight JDBC. If you are championing this as an approach, be sure to do your homework about the pros vs. cons of ORM vs. JDBC.
If you go with JPA, once you've reached the learning curve it will pay off in terms of simple development (particularly if you properly implement the abovementioned DAO pattern), but also in getting multi-tiered caching of query results. If done properly (a big "if", I know), I have seen this provide handsome benefits.
Lastly, if you have a legacy data model that you have little flexibility with, Hibernate (and JPA) will give you more headaches than maybe worth. For example:
要向列表中添加另一个选项...请查看：
Ebean ORM (http://ebean-orm. github.io）。
它的主要主张是比 JPA 或 Hibernate 更简单、更直观的编程模型。 具体来说，它没有 Hibernate Session 或 JPA EntityManager，没有分离/附加对象（没有合并、持久、刷新），延迟加载就可以了。
...也就是更容易使用和理解。
您还可以将自己的 SQL 与 Ebean（用于查询、更新、存储过程）结合使用，在我看来，它在使用您自己的 SQL 的易用性方面与 Ibatis 相匹配。
如果您想在 Java SE 中使用 ORM，那么我建议您查看一下。
干杯，Rob。
To add another option to the list... have a look at:
Ebean ORM (http://ebean-orm.github.io).
It's main claim would be a simpler more intuitive programming model than JPA or Hibernate. Specifically, it doesn't have a Hibernate Session or JPA EntityManager, no detached/attached objects (no merge, persist, flush), lazy loading just works.
... aka much simpler to use and understand.
You can also use your own SQL with Ebean (for queries, updates, stored procedures) and IMO it matches Ibatis in ease of use wrt using your own SQL.
If you are looking to use the ORM in Java SE then I'd suggest you check it out.
Cheers, Rob.
我们目前正在开发一个同时使用 Hibernate 和 ibatis 的项目。
为什么使用休眠？
它支持我们的领域模型、关系和继承。 我们有一个相当复杂的域模型，hiberante 很好地支持它。
无需担心写入插入、更新等。
Ibatis仅用于查看。 有查询，我们有与查询映射的视图对象（类似于域模型，但不是域模型）。 Ibatis 在您想要的视图对象中返回数据，而不必担心从结果集中读取数据，而您必须在 Spring JDBC 中管理该结果集。
为什么我们不使用 HQl 或 Spring JDBC？
该领域非常复杂，在渲染视图时，我们进行计算、分组和大量本机 SQL 函数。 我们在查询中完成所有这些工作，使用动态查询，在 ibatis 中管理条件并获得一个干净的轻量级对象。
如果您必须遍历多个层才能在休眠中获取数据，则更有意义
因此，根据您的具体情况，您可能只想使用一个、两者都使用，或者也可以不使用。
但可以肯定的是，hibernate 并不是你离不开的东西。
We are currently working on a project which uses both Hibernate and ibatis.
Why use hibernate ?
It supports our domain model, relationships and inheritance. We have a pretty complex domain model and hiberante supports it very well.
No need to worry about writing inserts, updates etc.
Ibatis is used only for view. There are queries and we have view objects(similar to domain models but not domain models) which are mapped with queries. Ibatis returns the data in the view obejct you want without worrying about reading from result set , which you have to manage in Spring JDBC.
Why do we that instead of using HQl or Spring JDBC ?
The domain is so complex and when rendering view , we do calculations , group by and tons of native SQL functions. we do all that in query, use dynamic queries , manage conditions in ibatis and get a clean light weight object.
Makes much more sense if you have to traverse down multiple layers to fetch data in hibernate
So depending on your situation , you may want to use only one, both or may be none.
But definitely, hibernate is not something you cannot live without.
请注意，在重要的多线程应用程序中使用 JPA/Hibernate（可能还有大多数其他 ORM 解决方案）可以很快成为真正的 PITA，因为数据库会话需要仅限于一个线程（Session 对象不是线程安全的）。 添加延迟加载以及持久实体最多可以属于一个活动会话这一事实...您将经历一场地狱般的旅程...
您可能想看看 在*多线程* Swing 应用程序中使用 Hibernate 进行会话管理（或者只是搜索“休眠多线程”）。
我的经验法则 (YMMV)：如果应用程序不适合某种请求/响应周期（例如 Web 服务），那么您可能最好使用其他东西。
当然，另一种解决方案是以规避上述框架限制的方式设计应用程序。 更改应用程序的设计以使 XYZ 框架能够工作，但会留下不好的余味。
无论如何，只是我的 0.02 美元
Be aware that using JPA/Hibernate (and probably most other ORM solutions) in non-trivial multi-threaded applications can quickly become a real PITA because database sessions need to be confined to exactly one thread (Session objects are not thread-safe). Add lazy loading and the fact that persistent entities can belong to at most one active session...and you're in for a hell of a ride...
You might want to have a look at Session management using Hibernate in a *multi-threaded* Swing application (or just search for 'hibernate multi-threaded').
My rule of thumb (YMMV): If the application does not lend itself to some kind of request/response cycle (like a webservice for example) , you may probably be better off using something else.
Of course, another solution would be to design the application in a way that circumvents the mentioned framework limitations. Changing an application's design so I can get framework XYZ to work leaves a bad aftertaste though.
Anyway, just my $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 也无法与构建安全的动态查询（无论多么复杂）相媲美。
I think that we should take in consideration the main reason why we're using Java (or OO).
The system has to be flexible and allow constant modifications of the specification (this happens very often in real life). Otherwise we should have programmed in C, because it's a lot faster.
I think that the best stack for web applications would be Java EE: JPA - EJB - JSF (with extended persistence context conversation scoped).
JSF also is slower than pure JSP/Servlet, but it's faster to develop.
JPA is harder to learn, but it's faster to develop (you know: RAD) and changes don't have big (error prone copy-paste) impact. Add a new column in your most used entity, and you will have to update all statements in iBatis ...
JPA doesn't work very good on all cases, but it covers most of them, and it also let you plug Native Query instead of JPQL without changing any code. But if you find yourself writing too much Native Query your project's might fit better iBatis.
And as for performance, JPA is also performant if you understand how things translate to SQL, and if you put it to do what he is best at, if you put it to do something that's not comfortable for him, it will generate too much queries. There's no magic ! You have to be aware of the generated query, not blindly hope that you can take the easy way when some complicated case might appear.
Also if developers have all the capabilities of SQL they will write too complex queries to process business logic, instead of having it in a centralized place, you will have some business logic in SQL, some in EJB. JPA should be for persisting your model, not for Business Logic.
Criteria Query is also no match for building safe nomatterhowcomplex dynamic queries.
如果您确实有一个新建项目，您可以使用 hibernate，但要注意学习曲线相当陡峭。
如果您有一个现有的数据库，那么使用 iBatis 会更好，因为一天后您就可以提高工作效率，再过两天您就可以了解它的全部内容。
您必须考虑的一件事是，hibernate criteria api 非常适合创建自定义查询，这取决于您的应用程序，可能是一个很好的论据。
If you are indeed have a greenfield project, you may use hibernate, but be aware that the learning curve is quite steep.
If you have a existing database you are much better of with iBatis, because after one day you are productive and after two more days you can know all about it.
One thing you have to consider is, that the hibernate criteria api is excellent for creating custom queries, which depending on your application, may be a good argument for it.
如果没有良好的对象模型，我看不到 Hibernate 的好处。 ORM 中当然有“关系”，因为你有一个关系数据库，但“对象”是关键。 没有对象，就没有 ORM。 我认为对象和表之间的 1:1 映射如果没有更丰富的对象行为，并不能证明 ORM 的合理性。 如果您的情况是这样，请坚持使用 JDBC 或 iBatis。
If you don't have a good object model, I don't see the benefit of Hibernate. You certainly have the "relational" in ORM, since you have a relational database, but the "object" is key. No objects, no ORM. I think a 1:1 mapping between objects and tables, without richer object behavior, does not justify ORM. Stick with JDBC or iBatis if that's your situation.
我建议使用 JPA 并（很大程度上！）取决于项目的持续时间/范围，您也可以研究一下 JPA2，因为它提供了 JPA 的一些缺失功能（例如，一个非常好的查询 API）。
I'd suggest going with JPA and depending (heavily!) on the duration/scope of your project you might as well look into JPA2, for it provides some of the missing features of JPA (a very nice Query API for example).
去冬眠吧。 您的项目以后肯定会变得更大，并且（学习 hibernate 的）投资将以某种方式得到回报。
Go with hibernate. Your project will definitely grow larger later on and the investment (on learning hibernate) will pay off one way or another.
在决定使用哪一个工具之前，您是否尝试过回答为什么要使用 ORM 工具？ 如果您的团队中有人了解 SQL，请参阅坚持使用 JDBC。
Have you tried to answer WHY even use an ORM tool before deciding which one to use? If you have people on your team who know SQL, see stick to JDBC.