Rob Conery, apparently bored again, decided to post a rant/whine/something about ORMs, apparently because of something Ayende posted. Apparently. It looks like this is a topic that he’s been thinking about for a while, so maybe Ayende’s semi-flamebait post was just the trigger. I don’t know. Anyway, Rob posted an initial commentary, and then, because he’s a wuss sensitive soul, he deleted it, and posted an edited commentary. I have the initial commentary since my RSS reader grabbed it, and I’m not sure exactly why he deleted it, as opposed to just posting a follow up. I didn’t think it was that obnoxious, but that could be because I use myself as a reference point for what is obnoxious, and, like at least 87% of humanity, Rob is less obnoxious as I am. I just thought it was, well, kind of dumb.
Anyway, out of laziness and to avoid that evil paraphrasing thing, a few quotations from el Robbo, and my comments:
“Developers are so fixated on data persistence that it’s utterly mind-numbing. I’ll go even further – this fixation on the basics is rusting and corroding the whole .NET coding existence.”
Note the embedded link, it leads to this gem:
“I think, in general, the .NET crowd overthinks and over-engineers just about everything”
It’s hard to know exactly what to say about this, but that’s never stopped me before. One of the things I prefer about .NET is that it is, in general, depending on what you are looking at, a hell of a lot less over-engineered than, say, Java. I know there are a lot of lightweight frameworks around now, but seriously, there’s some major suckage there.
Also, the reason why developers think about data persistence is because, oh, I don’t know, maybe because it is often a major business and/or functional requirement. The non-tech types understand the idea that data sits in tables and you can get to it, read it, and (maybe) do stuff to it. ORMs exist so that developers can get the data in tables the easiest way possible, without entirely screwing up their day.
Rob knows this, of course, so obviously there is something else on his mind. Maybe this is it (emphasis in original):
“right now there really aren’t any terribly viable solutions that will offer developers the level of familiarity and security that a relational system will – because we haven’t asked for one.”
This, of course, is just nutty. We do, via ASP.NET MVC, have evidence that there are at least some people at Microsoft who care about what developers think, but in general, software vendors care a lot less about what developers want, and a lot more about what customers want (devs can be customers, of course, but think Venn Diagram and small intersection). If customers were asking for non-relational systems, Oracle and Microsoft would build them (more on this in a second).
A bit more:
“Using Object storage mechanisms such as a document database or Object database is a great alternative to the ever-present impedance mismatch issue but it clearly needs some proof and testing.”
I’m going to go beyond Rob here, and just state something in the clear: the ‘ever-present impedance mismatch issue’ is basically a lot of shit. Is a relational model different from an object model? Yep. If you are using an object model and a relational model, will you need to figure out a way to map between the two? Yep. Will dumb people f%^k this up? Yep. Will smart people sometimes f%&k this up? If they are ignorant, sure.
But, at this point, is this really an issue? Nope. It’s a solved ‘issue.’ And object databases will never take off unless and until Microsoft and Oracle provide their own solutions. You can fake it anyway. Create a table with an ID column, and maybe a version column, then add a column of xml datatype. Persist your objects to that column. Done.
Developer friction is, in almost all circumstances, the least important problem. I have to continue the ‘poor man’s kanban’ series, but if you do a value stream mapping of the entire ‘production line’ involved in your software processes, developer friction isn’t the bottleneck. Focusing on that is time wasted that could be spent on other things.
This isn’t to say you shouldn’t try to reduce developer friction, or ignore CouchDB, db4o, blah blah blah. Rock on with all of that. And Rob will probably end up doing things that are helpful in this area. He’s good at that.
But, really, ORMs aren’t a problem. There’s nothing to worry about here.