Link Details

Here's the comment I added to his blog (in case it gets "moderated").

There are so many misapprehensions in this article that it's difficult to know where to begin.

First, the term "impedance mismatch" was coined by programmers rather than the marketing department of any company. It refers to the *conceptual* mismatch between how entities are related to one another (primarily via associations and specialization/inheritance) in object-oriented systems vs relational systems. And it is a completely valid description of a very real phenomenon -- one which becomes especially obvious in a domain model with deep inheritance hierarchies.

Second, an ORM tool can perform an insert in only one line of code so, by your (false, arbitrary) metric involving lines of code required to perform a task, your "simple" approach should be discarded out of hand as it provides no additional value compared to an ORM.

Third, your assertion that business logic should be placed in triggers has the obvious and well-known downsides that 1) your business logic becomes tied to a specific database, often using a proprietary stored procedure language and 2) this approach virtually guarantees an anemic domain model as well as business logic that is split across your application code and your database, and therefore far more difficult to debug and maintain. Hopefully it goes without saying that an object-oriented language such as Java or C# is far better suited to expressing complex business logic and validation than PL/SQL or a similar stored procedure language.

Fourth, your example using iteration misses a number of key points. 1) In an ORM, the iterative approach may very well perform better than equivalent "raw" database operations since the ORM will take advantage of an in-memory object cache which, if properly tuned, will eliminate most individual object fetches. Most modern ORM's (all of them that I know of) also have tunable fetching strategies specifically designed to avoid the "N+1" problem to which you allude. These can be used with or without a cache and will cause the individual object retrievals to be batched for efficiency. 2) Most ORM's have specific support for batch operations (i.e. inserts, updates and deletes) so that your code can be written in an iterative form (often a good choice in an OO application) but the database operations will be submitted as a batch, whose size can be tuned for optimal efficiency. JDBC itself also has batching support which any ORM will take advantage of. 3) At least in the case of Hibernate, a good deal of the documentation describes how to use options 1&2 precisely to avoid inefficient, iterative database operations. So it is ignorant at best and misleading or disingenuous at worst to say that ORMs "encourage" this type of inefficient database usage.

A primary theme of modern, large-scale system architecture is to "background" the database so that it is used only for simple persistent storage and eliminated as a performance bottleneck. The advice you are giving here is simply a throwback to the widely discredited and mostly abandoned practices of rowset-oriented client/server architecture. There are new, exciting and far more powerful approaches to system design available these days. I suggest you look into them.

"Why I Do Not Use ORM (and still have to give you my uninformed opinion)" fails as an article because of the reasons rholmes mentions (nice writeup, by the way). Most of the criticism simply does not apply to modern ORM systems. Underlying most of the article however is the trivial insight "leaky abstractions are leaky", which simple means any abstraction (in this case ORM) that is used in a blind and naive manner (in this case: using ORM without considering the resulting SQL statements and database behavior, escpecially for large production databases) will result in slow and buggy applications. Which is really the same with any other framework that tries to shield the developer from some underlying complexitiy. It's the sole reason any mission critical software must always be implemented one layer below what you would normally choose. I would never implement critical banking software with Hibernate, because I cannot predict exactly what the Hibernate code will do in all possible situations, and checking and controlling the resulting database interaction will be so much of a hassle writing my own project specific ORM is easier (and more time efficient, not talking about peace of mind...). However for most projects off-the-shelf ORM is just fine, given that you know what's going on under the hood and are able to tweak the handful of places the default configuration and mappings would horribly screw you. But that's our job as competent developers, isn't it? :)

eek - I think I need to write a whole blog post to respond to this one. :/ I think the general premise that "programmers use ORM to avoid writing SQL" is just inaccurate. I think it's also (generally) a bad idea to put any kind of business logic inside a database trigger, which the author seems to be advocating.

I didn't downvote it, because it's fairly well-written, and I try not to downvote just for disagreeing with someone, but I've gotta say that this one misses the mark...