This was also posted at: http://www.theserverside.com/news/thread.tss?thread_id=29140#144480
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!
