This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: The Object Relational Siren - put to death
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I had this discussion with Clemens when he was last here in Israel - his position, as was so eloquently stated here, was against, while I was pro. The question he raised "To map, or not to map?" he himself answered, "to map". The question remaining was how to map; write the sql yourself, or let some tool write/generate it for you.
The overarching question is: what do you REALLY gain by O/R mapping?
(As an aside, among the comments of his post are those using the acronym ORM. Please stop - that acronym is already taken by Object Role Modeling.)
I've been using O/R mapping techniques on mission critical projects for some time now, and if I wanted to compare it to what I did before, it would not be to writing all the sql by hand. I don't remember ever doing that - there was always code generation involved. Because, let's face it - there's a lot of drudgery involved for things that aren't performance critical. No reason to do THAT by hand.
So, for me, the ONE THING that O/R mapping gives me better than what I did before is this:
O/R mapping gets me better object-oriented business logic.
That's it.
Like Clemens said, if you "don't know SQL and RDBMS technology in any reasonable depth", don't expect to get good performance. Obviously this is true for any technique. But I guess that empirically speaking, the percentage of people without said knowledge is larger in the group where you don't HAVE to write sql.
So, I'll bet you're asking yourself, "if that's all Udi gets from O/R mapping, why does he keep doing it?" Or maybe you're asking yourself "should I get a beer? This is getting long..."
The fact of the matter is that I don't know a better way to write business logic than by using OO techniques. I grant that data is important, but the reason that many applications are built is business logic - there's something that this new system can/should do, that the old systems couldn't (often using the same data).
If I could sum up my understanding of Clemens position, it would be this:
A lot of developers probably aren't experienced, or knowledgeable enough the use O/R mapping well. Therefore writing the sql yourself is better.
While I agree with the first statement, and I think that the same could be said about communication, threading, .net and many other things, I don't think that the conclusion logically follows.
So, I guess I would sum up my position like this:
If you would like to develop a persistent domain model, O/R mapping techniques will probably help you. If you would like your solution to perform well, you should probably learn how databases work, as well as what the O/R mapping tool does under the covers.
Previous Topic
