Lightweight Frameworks, Again

A couple weeks ago, I wrote a post noting that I liked the lightweight nature of the Ruby web framework Merb. Today comes the news that Merb and Rails will be merging in Rails 3. People who see Merb as the "anti-Rails" seem to find this surprising. But people who see Merb as "Rails done right/better" are enthusiastic about it. It's hard to blame the developers for being more interested in pleasing the latter group. When you read through the list of "What Does That Mean, Exactly?" at this link, I don't see a downside to this. Rails is going to pick up many — or maybe all — of Merb's best design attributes, and folks who want to use Merb won't have to justify why they decided against Rails.

I'm going to tell another story which might not seem related at first. But I have a point, I promise.

In the middle of last year, we started a new project based on the ASP.NET MVC framework and the Entity Framework, both of which were essentially beta projects at the time. Despite some (entirely expected) pain from the shifting nature of data frameworks, the project progressed remarkably quickly, and we have begun shipping it to paying customers.

We had planned on using ASP.NET Dynamic Data, but we had to drop that very early in the project. The first thing that you have to do when using Dynamic Data is to call RegisterContext, passing your model, which can be an Entity Framework or LINQ to SQL model. Why only these two frameworks, when both return materialized .NET objects with rich metadata? Good question. What if I don't want to surface Entity Framework instances in my web application, but prefer to use lightweight data transfer objects instead? What if I don't want to use the Entity Framework at all?

Worse, the initial release of Dynamic Data cannot handle Entity Framework models containing many-to-many relationships, even though support for these is one of the more significant features that the Entity Framework has over LINQ to SQL. Worse still, Dynamic Data provides no way to scaffold only a subset of your model. I would have been perfectly happy if Dynamic Data just couldn't provide scaffolding for tables with many-to-many relationships, but could handle other things. Unfortunately, any one thing which Dynamic Data cannot handle in RegisterContext means that you cannot use Dynamic Data at all. So we didn't.

The non-support for many-to-many relationships will be fixed in a forthcoming version of Dynamic Data, and you can get a preview version now. I expect we'll give it a try, because the framework has a lot of promise, and portions of it are very nicely done. But part of me wonders which other, entirely legal, things might be lurking in our Entity Framework model which might make Dynamic Data die a speedy death. I don't see any mention of removing the restriction that Dynamic Data must understand your entire model before it can do anything at all. Even if it does understand our model, I wonder what will happen if I hand it a type which doesn't happen to be in that model?

This is an area where laziness could be a virtue. Obviously, Dynamic Data needs some sort of metadata model from which to produce its scaffolding. But if it waited to generate this model for types until they were actually needed, it would not die because it didn't handle something which the application didn't ever have a need to have scaffolded. Moreover, I think it's the desire to create a metadata model for every type you might possibly want Dynamic Data support for during the entire lifetime of the application upfront which led to the design decision to support only the Entity Framework and LINQ to SQL. If you create the metadata models on an as-needed basis, using Entity Framework or LINQ to SQL knowledge where possible to enrich the models, then you don't need a single model in a "known" framework as a starting point.

So the lesson here is that, even within a single-vendor ecosystem such as the standard portions of the Microsoft .NET Framework, dependencies on other projects can be lethal.