The best DSL I've ever seen for working with data is SQL.
- Rob Conery, Thoughts on WebMatrix
The last mile is what kills object-relational mapping. Rails ActiveRecord does not try to go the last mile.
- Paul Wilson,
The Vietnam of Test Driven Development
The Vietnam of Test Driven Development
Abstracting SQL often isn't a good idea from my experience
- @codemonkeyism on twitter
I have a high opinion of StackOverflow. What they accomplished in a very short time is amazing.Reading the news that StackOverflow is writing its own object-relational mapper made me think ...
As a consultant I have seen almost no project that did not run into troubles with their ORM infrastructure at some point in time ...
... so maybe Ted Neward was right when he claimed that ORM is the Vietnam of Computer Science more than five years ago.
I cannot make my mind up on this one...
On one hand, I am a big fan of ORM. I am regularly teaching JPA.
On the other hand, I am tearing my hair out, again and again, fighting with ORM frameworks, trying to persuade them to do what I actually want (usually having a very clear idea what I want but having to shave yaks to get there, while in most specific cases it would be easy to just write the SQL I want).
Maybe it is the ORM frameworks that are the problem?
For advanced usage scenarios it often feels like ORM frameworks are adding a lot of accidental complexity.
But then again, I think ORM itself represents an essential complexity that always surfaces one way or another... sooner or later ...
The ORM-Vietnam-Hypothesis talks about quick initial successes and the Law of Diminishing Return.
Now here are some interesting questions:
- How valuable are the initial successes?
- How long lasts the phase of initial successes?
- How can you prolong this phase?
- How can you reliably detect that the law of diminishing return kicks in?
Is it possible to somehow leverage the phase of initial successes and then stop at the right moment and turn to a better solution without loosing all the initial sucesses?
Is that what StackOverflow is doing, turning away from Linq2Sql now, going for a custom ORM solution?
StackOverflow started in 2008 and has gone through an amazing evolution since.
They started with a very simple programming stack and very modest hardware, with only some part-time programmers (as far as I remember from the Hanselminutes podcast). Yet they were able to create a product that influenced the live of most modern programmers...
To achieve this, they had do choose the most pragmatic solutions. I guess Linq2Sql was the obvious choice ...
Would StackOverflow be better off if they started with their own ORM implementation from the bginning?
Probably not ... I guess they would be at the same point now: They would have to rewrite it today based on their real world requirements and their experience from the last 2 years.
It seems that this leads us back to the principle that Premature Optimization is the Root of all Evil...
Could this be a general advise: ORM frameworks being there to get you off the ground easily, but prepare for a rewrite later, at least for some parts of your application?
Don't invest too much in your ORM infrastructure, so that you can't turn your back on it once the Law of Diminishing Returns kicks in?
... and how to achieve this efficiently?
While I was writing this post Hanselminute 262 was published, interviewing Sam Saffron and Rob Conery about their Micro-ORM implementations Dapper and Massive.
Interesting ... Micro-ORMs as the shiny new thing between the overblown swiss-army-knife-style-ORM and the not-invented-here-do-it-yoursef-style-ORM?
The podcast also talks about the fact that a simple "in-line" style of writing apps with fewer abstractions is becoming stylish again ... right the style we condemned and tried to get away from 15 years ago... and how this is related with a modern "getting things done"-mentality ... very interesting indeed.
