tags:

views:

5633

answers:

10

It's a pretty open ended question. I'll be starting out a new project and am looking at different ORMs to integrate with database access.

Do you have any favorites? Are there any you would advise staying clear of?

+12  A: 

Hibernate, because it's basically the defacto standard in Java and was one of the driving forces in the creation of the JPA. It's got excellent support in Spring, and almost every Java framework supports it. Finally, GORM is a really cool wrapper around it doing dynamic finders and so on using Groovy.

It's even been ported to .NET (NHibernate) so you can use it there too.

Abdullah Jibaly
I vote Hib too, but with an important addition: we should use JPA API *only* even if JPA implementation is in fact provided by Hib.
Vladimir Dyuzhev
+3  A: 

SimpleORM, because it is straight-forward and no-magic. It defines all meta data structures in Java code and is very flexible.

SimpleORM provides similar functionality to Hibernate by mapping data in a relational database to Java objects in memory. Queries can be specified in terms of Java objects, object identity is aligned with database keys, relationships between objects are maintained and modified objects are automatically flushed to the database with optimistic locks.

But unlike Hibernate, SimpleORM uses a very simple object structure and architecture that avoids the need for complex parsing, byte code processing etc. SimpleORM is small and transparent, packaged in two jars of just 79K and 52K in size, with only one small and optional dependency (Slf4j). (Hibernate is over 2400K plus about 2000K of dependent Jars.) This makes SimpleORM easy to understand and so greatly reduces technical risk.

David Schmitt
Is it like ActiveObjects?
Adeel Ansari
Haven't used it, but ActiveObjects describes itself as sort of a Hibernate-lite on their website, so there probably is some similarity.
Abdullah Jibaly
A: 

Pluses for Hibernate are that it is a de facto standard and is well documented. Negatives are that it has some nasty little quirks (including a fondness for failing silently) and the JAR dependencies are a mess. Also, the development team has a reputation for being somewhat tetchy (which is only an issue if you might need their help).

If you're specifically looking at JPA implementations, you might also consider Open JPA, which is much saner, though not nearly as widely used. There is also Toplink, but I have no experience with that (other than a co-worker telling me that his project had stopped using it and switched to Hibernate because Toplink was "****ing ****").

Dan Dyer
I really would like to know what kind of issues they had with TopLink Essentials (which is JPA 1.0 reference implementation). Even if I really like and prefer Hibernate, TopLink was more than a decent product and has proven success. I thus find hard to believe that TopLink used for a JPA implementation (TopLink Essential) suddenly became ""****ing ****".
Pascal Thivent
A: 

Eclipse Link, for many reasons, but notably I feel like it has less bloat than other main stream solutions (at least less in-your-face bloat).

Oh and Eclipse Link has been chosen to be the reference implementation for JPA 2.0

instanceofTom
+9  A: 

I have stopped using ORMs.

The reason is not any great flaw in the concept. Hibernate works well. Instead, I have found that queries have low overhead and I can fit lots of complex logic into large SQL queries, and shift a lot of my processing into the database.

So consider just using the JDBC package.

David Crawshaw
It's the same story over and over again with ORM: nice quick initial development, and a big drain on your resources further on in the project when tracking ORM related bugs and inefficiencies. I also hate the fact that it seems to give developers the idea that they never have to write specific optimized queries.
Eelco
Hey, is this all true for big real life projects?
santiagobasulto
+2  A: 

None, because having an ORM takes too much control away with small benefits. The time savings gained are easily blown away when you have to debug abnormalities resulting from the use of the ORM. Furthermore, ORMs discourage developers from learning SQL and how relational databases work and using this for their benefit.

simon
I agree with this statement. How much from the total development time will be consumed by writing persistence code? I think less than 10-15%
adrian.tarau
It depends. Sure, if you're using just one particular kind of database, it's easy to get away with not using an ORM. However, when you need to support other kinds of databases, it can quickly become less manageable.
Jason Baker
+1  A: 

I had a really good experience with Avaje Ebean when I was writing a medium sized JavaSE application.

It uses standard JPA annotations to define entities, but exposes a much simpler API (No EntityManager or any of that attached/detached entities crap). It also lets you easily use SQL queries or event plain JDBC calls when necessary.

It also has a very nice fluid and type-safe API for queries. You can write things like:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();
IgKh
I must be a little bit weird... select from Person where gender = 'M' and age < 18 ordered by firstName just looks so much better to me :-)
Eelco
This is one of the better orms I've seen in java. It's decision to use a singleton is refreshing and gives it a massive practical advantage over the others.
opsb
+4  A: 

Hibernate, because it:

  • is stable - being around for so many years, it lacks any major problems
  • dictates the standards in the ORM field
  • implements the standard (JPA), in addition to dictating it.
  • has tons of information about it on the Internet. There are many tutorials, common problem solutions, etc
  • is powerful - you can translate a very complex object model into a relational model.
  • it has support for any major and medium RDBMS
  • is easy to work with, once you learn it well

A few points on why (and when) to use ORM:

  • you work with objects in your system (if your system has been designed well). Even if using JDBC, you will end up making some translation layer, so that you transfer your data to your objects. But my bets are that hibernate is better at translation than any custom-made solution.
  • it doesn't deprive you of control. You can control things in very small details, and if the API doesn't have some remote feature - execute a native query and you have it.
  • any medium-sized or bigger system can't afford having one ton of queries (be it at one place or scattered across), if it aims to be maintainable
  • if performance isn't critical. Hibernate adds performance overhead, which in some cases can't be ignored.
Bozho
woops, seems somone has edited his answer thus digging the topic, and didn't look at the question date..
Bozho
+1  A: 

I would recommend using iBatis.It is a thin layer on top of JDBC, it is very easy to map objects to tables and still use plain SQL, everything is under your control.

adrian.tarau
Ibatis for complex reads, and hibernate for create, update delete and simple reads is perfect choice.
darko petreski
A: 

I've been pondering the same question myself and have decided to go with Apache Cayenne.

ssakl
no it doesn't. You can use annotations.
Bozho
@Bozho - Didn't know that. I've edited my answer.
ssakl