h1

To ORM or not to ORM, that is the question

February 12, 2009

What is the best way to access a relational database from an object-oriented application?

I understand OOP. I understand relational databases. Assuming the database is wafer-thin (just tables) and that all of the logic lives within the application, there are various ways to get the two working together. In Java-land, JDBC provides a mechanism to write real SQL in your Java application. For each such query, you (as the developer) are responsible for providing the mapping. Spring’s JDBC templating provides a slightly easier way to implement the same functionality. ORM frameworks have also been around for a while. My initial impressions after using JPA/Hibernate for the past few months:

Benefits

  • You specify an annotated domain object and JPA magically does (reverse-)mapping between the object and the database table.
  • You are abstracted away from the different flavours of SQL that different databases use.
  • CRUD operations abstract relational concepts from OOP land.

Drawbacks

  • Defining complex relational queries in OO ain’t easy. It’s certainly hard to define and is most likely not the most efficient. I have never worked with OO databases but if I am going to specify all (or most) of my database access with object oriented constructs, why not just try an object oriented database instead? I realise they don’t have the same reputation as relational ones, but why not, in this case?
  • I don’t know if others have the same problem, but I seem to have a REAL problem understanding a database transaction (the @Transaction annotation in JPA land) in the context of object oriented code. Especially since I don’t understand how much Hibernate caches and when it actually flushes and synchronises with the database.

Reading documentation hasn’t really helped either – I probably need to create tests with several different scenarios to see what really happens underneath. And until I do that, I will hesitatingly continue to use JPA, while nostalgically remembering the explicit control of JDBC and raw SQL.

Advertisements

6 comments

  1. I tend to agree with most of this. I think the other huge benefit is the massive simplicity for simple updates. Simply “find” the object (row) that you want and then update it’s properties – Done. No boiler-plate code, not even a line of code to tell the DB to be updated, it just does it.

    Of course, “when” it does it is the bit that’s not really apparent.


  2. Can you do both? Or does the ORM change the behaviour of the database? Could you use ORM for simple find and update and Spring/JDBC for more complex queries?


    • That’s an option (that I like) but one I doubt will get much traction. I don’t think most people would like to have an application with two different data sources hitting the same database.


  3. I can understand the concern with two data sources (though I can’t imagine any concerns over race conditions), but surely using a tool to do basic CRUD will speed up development, with custom JDBC code in the model class to abstract what source is used to compliment.


    • You’re right, race conditions wouldn’t be a factor because each operation would be in its own database transaction.

      The abstraction, however, could get a little tricky. When using Hibernate, for example, once you retrieve an object from the database, any edits made to the state of the object (even from the service layer) are persisted into the database without an explicit command to update. On the other hand, you should explicitly persist when using custom JDBC code. Care should be taken that updated objects aren’t persisted carelessly – and I’m not sure that’s very easily done.


  4. I must say, I could not agree with you in 100%, but that’s just my IMHO, which could be very wrong.
    p.s. You have an awesome template . Where have you got it from?



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: