Thoughts on EF vs. NHibernate Redux

Saturday, December 26, 2009 -

Note: I posted this yesterday and violated a prime rule of mine: don’t blog when frustrated. I’ll admit it – this conversation frustrates me as it has derailed so many architectural discussions I’ve had over the years. Sometimes, when frustrated, I spend a bit too much time on the negative. I’ve revisited this post with a bit more thought after a rather “short” conversation on Twitter with my friend Rick Strahl, who had some good points which I crapped all over ;).

I read through Oren’s “What can EF do that NHibernate Can’t” post the other day, and his response to some of the thoughts today and I was about to leave a comment but I thought “maybe I’ll just post a blog myself”. I am pretty opinionated about this stuff and usually I just walk away from “tool arguments” because they usually stay just that – arguments. In this case maybe I’ll share my thoughts…

Thought 1: It Doesn’t Matter

You’re not going to change anyone’s mind, ever. Even if you did – it still doesn’t matter. Developers are so fixated on data persistence that it’s utterly m ind-numbing. I’ll go even further – this fixation on the basics is rusting and corroding the whole .NET coding existence. Because YOU are so focused on it, Microsoft is focused on it and rather than innovate, we refine. And keep refining until we’ve split off into camps and write posts like “Mine versus Yours” and people light torches and we as an industry go nowhere.

I have a pet project that I’ve been working on using Rails and the whole “just stop obsessing” feeling is so… very… freeing that I don’t know what to do with myself. I feel like all of a sudden a person I’ve been arguing with for years calls me says “hey sorry man, I was a real turd all these years and you’re awesome so here’s some beer”.

Actually it’s better than that. It’s a migraine subsiding, a massage just starting, a buzz just coming on, a first love just setting in, the day you get your driver’s license and pick up your friends, your first bike for Christmas, the first time you… well you know, a pair of shoes that just fit.

I understand that Rails ActiveRecord has it’s downsides – but for 90% of the people using Rails they aren’t a problem (and for what it’s worth we have all the same issues with every .NET ORM – select n+1, eager/lazy issues, mappings, blah blah blah).

Thought 2: There Are Other Choices

Object databases and Document Databases are on the rise. Approaches such as DB4O, MongoDB, and CouchDB offer fresh ideas and approaches to the core concept of data persistence. Yesterday when I posted this post Rick asked me (in summary) “it’s nice to complain, but unless you have a solution it’s hot air” and I agree with that sentiment.

But I don’t have a solution – and that was the point I was trying to get across: 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. Yes my mom’s old beat up minivan sucks but it gets me to work and I can’t afford a new one.

If you drive a beat up relational mapping minivan to work everyday, there are alternatives – they might seem odd and strange but consider that you’re not familiar with them just yet. They aren’t part of your normal day to day so they seem alien (most likely).

Let’s take my first suggestion: an object database like DB4O. I’ve written about using this thing before and I really, really like it. It just works most of the time, and yes there are quirks that one needs to get used to. Quirks like no visual designer, no visual editor that works (I’ve never been able to get it to work right), etc. But these are only quirks to folks who are used to working visually with a database – which is all of us. There’s a comfort level to actually seeing your data, adjusting the tables, knowing it’s there – and these are crutches.

So to Rick’s point: this is a simple alternative and yes there will be issues with it, but it’s an approach that can be massively improved upon. We’re 20+ years in to “app on top of RDBMS” and we’re finding out that it still hurts and that little issue of mapping tables to objects will always remain an issue.

Thought 3: This Requires Noise

I want to keep going in a positive direction, and I want to try and throw some momentum into seeking/supporting better solutions. One of the comments I’ve received was from Scott Bellware who notes the value of this discussion is the discussion itself (to paraphrase) and that knowing how we got here will help the community refine itself in the future. I agree with this – but it’s also lingering on the past just a bit.

I would love to have parts of that discussion, but with a broader approach – so to start the dialog:

I’d like to suggest we, as a community, focus some time and attention to alternative storage mechanisms and lend a hand to pull them up to acceptable levels.

By “acceptable levels” I mean ironing out the shortfalls and coming up with an architectural approach that makes sense to folks. For instance – I suggested before that your application’s data storage shouldn’t be mingled with your business/enterprise data store in the same way you keep parts of your application separate. The app is in the “DMZ” if you will – all data should be suspect and treated as if landing from Mars.

Given this approach your app is free to store data however it sees fit. But even this is just the start of a much bigger conversation – one that we’re not having because we’re addicted to the relational model – using cargo ship databases when all we need is bucket-sized fishing boats.

This happens by trying something new and perhaps blogging about it, discussing it openly, and making a bit of noise if you find a good pattern.

Summary

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 have a few ideas on how to get these things out in front of people for discussion, and if you’re an Open Source-y type person as well… it would be great to see you give this stuff a shot!

And with this post – I’m committing to coming up with architectural approaches and alternative based on real-world work. I’ll blog them in the future, but as of right now I’m going to start small and roll my blog here completely over to DB40 (or Mongo – haven’t decided yet) and I’ll blog it all.

It’s small, I know, but I do have some ideas on how the two can play nice and I’ll blog it – maybe even put a freebie screencast on Tekpub. I don’t like the thought of just “bitching” and not “doing” – I’m not that type. Just do me a favor and suggest some constructive alternatives rather than tell me it’s tilting at windmills – I refuse to believe we’re stuck here.