I Hate Persistence (but love Azure Table Storage)
May 12 2009If there’s one thing I can’t stand in the development process it’s writing code to save data. In fact, there are only a few things which I’d consider more useless than dealing with data persistence- one of them being data migration. I hate dealing with persistence because it’s totally mundane and repetitive code. Worse, nobody outside of IT really understands the details of persistence. Which means it has no business value. And why should users care about unit of work or active record vs. repository? Should saving an object really be that complicated of a task? Absolutely not. Which is why no one cares. It’s like caring about how your beer was delivered. Really, I just want to drink the damn beer. Yet somehow the thing which should be a no brainer takes the most time and effort to do. And causes the most debate. And causes the most problems. However, I recently got my first glimmer of hope- a cloud with a silver lining- that maybe, just maybe, someday, we’ll actually have simple data access.
We as a development community have been transfixed on data access strategies. It’s the great elephant in the room, and has totally consumed all our attention. It’s distracting. Only a .NET/Java language war in ’04 could rival such a fierce debate as between Ayende and Greg Young over the repository pattern. (My two cents: ActiveRecord. Just kidding, ActiveRecord sucks (not SRP). Use Subsonic– which lost me at “drag and drop”, but I would not want to piss off Rob Conery).
Why do I hate persistence? It’s never really gotten any better. The first major advancement came with sprocs. Everything had to be a sproc, and if you weren’t using sprocs then you just weren’t cool. You can do these great things with sprocs- like writing select statements with inner joins. But not in your vbscript! This mostly lead to awesome interview questions like “why are sprocs important” and dba’s who would whine about developers writing bad sql (guess what- they can write bad code too)!
Next, and silently from the Java community, we were given NHibernate and the concept of an object relational mapper. Suddenly, an awakening occurred, and we as developers could now stick it to those dba’s and there precious sprocs. Try changing my auto generated sql, you bastards! Unfortunately, the NHibernate craze did not take off. We gave up sprocs for those awful configuration files- as if things could get any worse! I personally have a big chip on my shoulder because NHibernate comes from the Java community. Java, after all, just sucks (sidenote: this a totally baseless claim). Fluent NHibernate doesn’t make it that much better: I’m not digging Cascade. All(). Inverse(). WithForeignKey(). WithIndex(). WithConvention(). ButNotForThisClass(). How. Many. Can. I. Add() and double code associations for parent/child relationships etc. Not a big win. But at least we can rub Fluent NHibernate in Hibernate’s xml hell! Yes, there’s the auto mapper configuration which I admit is slick- but you’re kind of locked into the default convention (over configuration). Stray from the path and you’re back in the configuration quicksand. And don’t even get me started on the NHibernate query syntax. Yes, there’s Linq to NHibernate, but why use that when you go directly to the best thing to come out of Microsoft since the Steve Ballmer video.
Finally there was a breath of fresh air, and Microsoft was awesome again. We were given Linq to Sql. But when Microsoft realized they did something cool, they quickly pushed for Linq to Entities (oh wait- Entity Framework- Linq to Entities sounds like the cool Linq to Sql). We were quickly back to the WTF relationship we have with Microsoft. If you want to know why EF sucks, just try using it. Or check out this good series of articles about l2s vs. l2e. I gave up on Entity Framework when I tried setting up an auto generated db value on an insert. It’s a pain in the ass and not nearly as simple as Linq To Sql’s “This is an auto generated property” property.
What are we left with? Just the endless data access debate. Which in a way is good for us because it keeps us from actually delivering something our users care about- like an app that saves data. (Um, why can’t I change the customer address and overcharge them for adventure works gear at the same time??!?!?!)
So where’s the glimmer of hope? Azure Table Storage- which might put us back in the Microsoft is cool again category. Don’t worry Microsoft- you only support sorting on only one field (“Choose… Choose Wisely”), so I’m sure you can still spark lots of criticism. But please give large bonuses to the people behind ATS. Why is it so great? The same reason Linq to Sql is great- it just works. ATS with ADO.NET Data Services is about as easy as you can do persistence without actually having to do it. (Side note: I’m ignoring object databases). But you really have true POCO storage. No messy attributes, no base classes, no schema generators, no xml configuration files, no .edmx files. You have an object- it has public getters and setters- and you can save it. That’s all you have to do. The catch? A row key and a partition key (Sidenote: I’m ignoring the whole deploy/run cloud part). I could live without the partition key, but you’re not really asking for much. What else? It’s built on Linq- and Linq, as we all know, is awesome (just like sql, but no strings!). (Sidenote: more criticism fuel: not all Linq operators are supported).
What else? ATS is also schema free, so no more entity/table mappings. Just save an object. In fact, save different objects in the same table. Like parent/child classes. Together. Like an aggregate root. Then search on any field (sorry, still no sorting!) That’s all you have to do. And did I mention there’s no schema migration? Because there’s no schema! We’re free! Freedom! Sure, it’s not the first schema free storage solution– but it’s the only one backed with ADO.NET Data Services. And that’s the special sauce which makes it yummy!
Yes, ATS isn’t perfect. In fact it’s far from perfect. But it’s a great step in the right direction. NHibernate, Linq to Sql, EF, sprocs are all usable tools (sorry, didn’t mean to include EF). There are some great 3rd party toolkits too, but if I have to pay for data access I’d like you to just do it or me. There has been a great effort in the OS community (FluentNHibernate is a huge win) to make this stuff easier, but the bottom line is you’re doing double programming: you got your db and your code, and all that stuff that sits between is just crap. Even with FluentNHibernate you’re just shifting your db programming to configuration. At the end of the day doing data access well isn’t even a win because the user still doesn’t have a damn form! ATS is different- it’s just really slick. It’s scary slick. Yes, it’s not ready for prime time, but it’s a huge step in the right direction.