ORM Vs SQL

There are two religious parties in java development world while dealing with persistence part of enterprise applications. It is one of the toughest decision Java architect has to make while joining any one party here.

1. ORM

2. SQL (JDBC).

Let me confess first, I belong to first party & here I am trying to put some arguments in favour of that. :-)

As the software evolving from monolithic programming to object oriented (We have procedure oriented, structured way of coding in b/w these two)the main motivating factor has been,

1. Code reuse (No code duplication) that improves time to market and maintanability.

2. Smallest possible lines of code providing the same result without sacrificing the readability & acceptable performance(Speed,memory etc...).

Hence the major criteria for assesing quality of the source code is reusability and maintainability.

Why SQL affects maintanability and scalability of application?

Working in Java - my business logic is object-oriented (With the advent of lightweight framework and domain driven design). As we cannot create well designed java application without (OOAD, all the data-models and queries that I need to construct separately & is definately duplicate my logic, even though I already have the same in my Java code I need to duplicate the same in SQL, so source code is defintely not going to be short.And worst part is every time I change my Java code, SQL also needs to be changed.

With ORM (Hibernate), we have persistence meta information in annotation ( with XDoclet) & we don't have to write any extra code if we change any of java code(for schema change). An ANT task should be able to do all the schema update. Database is a persistence layer. There is no need to know anything about persistence layer, except that it stores data persistently & that's it business logic should have nothing to do with it. ORM also gives RDBMS independence it can be huge benefit supporting business agility and avoiding vendor lock.

"PL/SQL provides better performance"
I don't think (from my experience) where well designed ORM fails on performance. Proper use of cache layer should solve the problem. Now cache frameworks are much matured, and ORM tools comes with out of box solution for the same.
Thinking about performance too much is counter-prodctive. It is always possible to revisit 5% of usecases where we might have to refactor to improve the performance with PL/SQL. With the productivity gain that we get out of ORM it is very much possible to absorb this 5% effort very easily in the end.

“ORM Learning curve is huge”
This is usual execuse given by the project development team & these set of lazy developers/managers who refuse to learn new techniques & happy using old worked solutions. Actually dead line pressure should be more strong reason to choose ORM. Nothing can be done to DBA paranoids who cannot (probably unwilling) learn and appreaciate the the importnace of Object orientation.

Having said that here I am not trying to downplay the importance of SQL. ORM tools are using SQL behind the scenes - that's what they do and I beleive Hibernate is the most popular exactly because Gavin King made it as SQL-friendly as possible. But it needs proper usage, that's all. One has to learn & appreciate the importnace of referential integrity and durabability that RDBMS has brought into the software and the huge cost/effort investment made in these RDBMS products will be valuable in the coming decades as well. We need to understatnd why it is an bad idea to run the same query in a loop, why there should not be many networking calls, why the query needs to be optimize to minimize the scan, why we should try to bring minimum possible data to presentation layers, why to device a way to handle open ended queries etc...

In situations like complex legacy model, Many set based operations (Batch updates/inserts), too much normalization or denormalization (No natural O/R mapping) ORM is definitely not a good candidate. It's a overkill.
In these scenario's also iBatis SQL map & Spring JDBCTemplate offers better value proposition.

Finally,
In any new development project there is no technical or political reason left to use plain JDBC/SQL solution for handling persistence layer.