I had dreams of this when I joined Microsoft a few years back – that SubSonic would be the database juice in the ASP.NET MVC story. Or if not the juice then the ActiveCherryOnTop.
The pieces didn’t quite fall into place, though I tried many a time. The issues that I faced were pretty simple – everything I tried didn’t quite fit. No one wants to take a dependency on a specific data access library (which is precisely the thing that Rails does most of the time – and it’s quite freeing to not think about it) – so working SubSonic into MVC didn’t quite fire on all cylinders.
It’s understandable – but I have a better idea now and I want to see if others are willing to engage with me on it. “Others” being the troupe of ORM-dudes out there: NHibernate, LLBL, and the for-pay guys…
Background
I’ve been talking to Phil of late (actually I’ve been mercilessly teasing him) about his work with the EF team on an ActiveRecord story for ASP.NET MVC. I understand the technical aspects of it, but the last thing I can get my head around is using EF to pump ActiveRecord magic into MVC. Sort of like having to ask the US Congress where the restrooms are…
Anyway I told Phil I’ve had a demo sitting here that I’ve been trying to spruce up a bit – a “SubSonic Starter” site for MVC if you will. I followed some patterns that I thought we could reuse for any ORM/DataEngine out there – and so I hit him up with the idea that I really like…
Elevator Pitch
Long story short – we geeked out for a few hours the other night and it was really fun. Here’s what we came up with:
- An “IActiveRecordEngine” API for MVC that would allow you to “plug in” your AR implementation in the same way you might swap out the ControllerFactory or ViewEngine. In the Global.asax you would just “SetActiveRecordEngine(new SubSonicActiveRecordEngine())” and off you go.
- Define an IActiveRecord interface for your objects to implement (stuff like Add, Update, Delete, etc)
- Create an opinionated Controller<T> that would use this so you don’t have to think about persistence ANYMORE. The idea would be you would use a RESTful approach (like Rails does) with your objects and have a Controller<Post> for example. This controller would already have the “magic 7” actions defined (or magic 5 – depending on how literal you want to be) for CRUD operations and you can add/override as you like.
In addition to that, the IActiveRecord interface would define some “sugary” methods such as “GetKeyName, GetKeyValue, GetDescriptorName, GetDescriptorValue” that would allow you to spin up UI elements with the HtmlHelpers. Something like “Html.ControlFor<Post>(x=>x.Title)”.
There’s so much we can do with this – all without caring about which persistence mechanism we use (EF, SubSonic, L2S, NHib – whatever) as long as they implemented the API. Yes – some would do the API better than others, and if that’s the case then your data story is solved isn’t it?
Doing It In Public
It’s tempting to “come up with a proto” and push it out there – and believe it or not I have one – but I’d like to see if I can take the lead on this and come up with an API that works for the most common scenarios. I understand that “opinionated” approaches to problems generally don’t work well with a committee – all the same I don’t want to do this in the dark.
Before I do anything (as I’m already stretched pretty thin) – I wanted to see what people thought of this idea. So – lemme have it! Good? Bad? Things you’d like to see?
I’ll tweak my prototype based on what you suggest here, and see what I can do with it next!
