To Hibernate or not? - A commentary on ORM’s and few recommendations
By Angsuman Chakraborty, Gaea News NetworkSunday, February 15, 2004
I came across the post from Jesus Rodriguez where he tries to find good reasons to convince management to use Hibernate.
[[I tried posting but it required me to create an account, also I felt that the topic might be of general interest. So I made this a separate post and included him in trackback & pingback.]]
In his case the company followed two models:
1. Contains all SQL in a single class
2. “One involves creating a helper object which exists between the domain object and a DatabaseCommand (our persistence class). The domain objects do not know how to generate SQL. They simply know that there exists a class that accepts helpers. The helper has methods like getStoreColumns() and getStoreValues() which return the columns used for inserts and their corresponding values, respectively. The helpers have direct knowledge of the domain object. The DatabaseCommand knows how to build SQL statements filling in the missing information by asking the helpers.”
He has described the pros and cons of the system in his post.
Couple of thoughts & suggestions:
In general, approach one has the benefit that creating SQL code can be delegated to database specialists. Also they can optimize the code in there later on (as it is all in a single big file) to eliminate bottlenecks or simply to speed things up.
Logically though the key value is in isolating the db code. Which can also be achieved by having the classes in a single package.
The second approach as you can see is cumbersome and is rather maintenance heavy.
The key issue is that in both cases a Object relational mapping is required. In a company I worked in the past they have created and maintained ( yeah I came in after the deed was done) a home-grown ORM layer. It was a nightmare because of the following key reasons:
1. It was hard to learn and complex to use
2. Complex queries were near impossible
3. Easy queries were very time consuming to do, thereby affecting productivity
4. Because of a general Object structure (we called them BoB - business object, I jokingly named the process bobification) type checking was non-existent thereby leading to hard to find bugs
5. Debugging was royal pain
What I learned from this was that maintaining an ORM is a full-time job, specially to make it usable in a wide range of occassions and still make it easy to learn. We are not in the business of ORM. We however need the functionaility. Why bother creating and maintaining a home-grown one? The focus should be on the core competency and surely ORM is not ours. Hibernate and other ORM layers relieves you of the pains. Most of them are easy to learn. I presonally try to avoid ones which tries to create its own sql syntax as it means I have to learn yet another SQL clone. Normally they also provide a QBE type interface, saw it in hibernate too. They are the easiest to use and really help in RAD.
Everyone you hire will have to learn about a home grown ORM, whereas you may get lots of people who have used Hibernate or OJB. Also for the developers it is a reusable skill.
I rest my case.
|
May 4, 2006: 7:02 am
Hi Thanks & REgards |
 Srinivas B. |
December 14, 2005: 11:40 am
What would be nice is to add another layer of abstraction within Hibernate to simply expose the legacy stored procedures out to the Java applications. The complexity comes from the fact that each Database out there has its own idiosynchrocies, but challenge is the word we developers like to hear :-), right? |
|
March 31, 2005: 3:31 pm
ORM is needed more often than most, if u have a large complex project ORM mapping of your data tier, is always the best approach it makes your project ‘mature’. |
|
February 16, 2004: 10:25 pm
Christian, your completely correct. Deciding if you need ORM can be answered by asking yourself the question: “Do I need my data as objects?”. If all you need is an in memory copy of the tables, then ORM is overkill. |
 Christian |
February 16, 2004: 6:35 am
You both are right. ORM is not the best solution (yet) for applications with mostly reporting functions. Stored procedures are a good choice for this kind of problem, as is for any mass data operation that doesn’t involve complex logic executed in the middle tier. I’d say that Hibernate has some interesting features for basic reporting as well, so you can easily write the aggregation queries for a typical report screen without leaving the mapping abstraction. |
 Juan Murillo |
February 16, 2004: 3:59 am
ORM is not suitable for every occassion. We for example needed to execute some complex manipulation on the database layer. We looked into Hibernate and it looked like it enforces pretty strict OO practices by default. We decided to give ourselves more flexibility, we built a DB abstraction object which accepts command objects from a command pattern implementation. This object then looks up the command on a table on the DB where it finds the appropriate stored procedure name and parameter list. The command object contains the necessary parameter values. The DB abstraction object executes the stored procedures and returns the appropriate command result object. All Sql code lives in the database itself, modification of this code can be done without redeployment directly in the Database. Even the contract for the stored procedures can be altered as it is defined in a table on the DB. When you interact with a DB you usually require a service (method oriented) and i find that allowing your objects to request this service natively as a method keeps our systems really clean and provides a total separation of layers. |
Kalukuri