This was also posted at:

The lengthy discussion, at that thread, itself - shows that this topic is not a simple one and there are plenty who take one or another side.

The liberals say: “it is a matter of choice and depands on what are your goals in a specific project”

Is it,really?

For me, there are two major criterias to assess the quality of a program code
1) (Almost) No code duplication
2) Shortest source code providing the same result.

I do beleive that these are not just my personal choices. I think those two criterias have proven to indicate to a reusable and maintainable (!!!) code.

Do not forget - the life of a code begins ONLY after it is deployed to the production environment and you have to maintain it! Until that - it\’s all jokes and fun. That\’s when the real thing begins and when it starts to HURT.

Thesis: Maintainability and Scalibility are the key!

So, then why do I hate SQL in my code? Because, working in Java - my business logic is object-oriented. You can _not_ create a well-designed Java application which is not OO. OK, my business logic is OO but then - I need to use SQL??? But all these data-models and queries that I need to construct separately - THEY DUPLICATE MY OO LOGIC!!! That\’s code-duplication! Also, I do have to write all that SQL manually, even though I already have the same in my Java code, so source ain\‘t gonna be the shortest! And - every time I change my Java code, I need to change SQL queries and table structure, too. Damn!

Who will argue that this does hurt both maintainability and scalability?

How do I modify my code with Hibernate? My persistence meta-information is in XDoclet form right in my Java-code. I do not write anything extra, outside the pure Java code. When I change something in the Java-code, I run my nice ANT task, which goes through the changed persistence configuration (auto-generated using XDoclet) and using Hibernate Schema Update, does ALL the necessary changes in the database. All I do is: type “ant database”.

For me, a Java architect, Database is a persistence layer. Why should I have Business Logic (!) in a persistence layer? I don\‘t want to know ANYTHING about my persistence layer, except that it stores data persistently. My business logic should have NOTHING to do with it!

This is why I would hate to see SQL in my Java code and as far as my thesis, above, holds - I can not be wrong.

But DB-centric advocates, also, have a “winning” argument, don\‘t they? What was that - “PL/SQL provides better performance”?

Well, we have worked with it, ok? :) PL/SQL can be damn slow, too! So there is no win - any DB access, via ORM, direct SQL or PL/SQL can be slow enough (usually is) to be too slow. That\’s why we have cache layer.

Well, good news - my ORM framework - Hibernate allows me to integrate different cache frameworks (from JBossCache to the wonderful - Tangasol Coherense) transparently. So, I do not have to worry about that, either, do I?

And in addition to all these - I can get RDBMS-independance, if I am careful enough. If my client suddently decides Oracle is too expensive, or new client comes that needs MySQL - here we go - I just smile slightly and say “sure, no prob!”.

Does not that feel great?

And last but not least - Nobody is trying to diminish 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 made it as SQL-friendly as possible. But it needs proper usage, that\’s all!