Hibernate, iBatis, Java EE or other Java ORM tool

Question

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

Answer 1

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

Answer 2

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.

• LGPL Licence
• Use JPA annotations for mapping (@Entity, @OneToMany etc)
• Session-less API (no merge, persist, flush ... save() and delete() instead)
• "Partial Object" support
• Large Query support (per object graph persistence context)
• Background queries
• Good support for batch processing
• Automatic Query tuning (via "Autofetch")

Cheers, Rob.

Answer 3

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.

Answer 4

Go with hibernate. Your project will definitely grow larger later on and the investment (on learning hibernate) will pay off one way or another.

Answer 5

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.

Answer 6

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