Meta-Meta-Programming … and I like it

I have a client that needs to rapidly create websites that are similar in functionality but needs to make changes to the data model (sometimes significant changes) and have the UI get updated with it, turning around a change within the day.

For this, I decided to base a solution around ASP.NET Dynamic Data for two main reasons: 1. It’s scaffolding concept and 2. The “generated code” has been tested already, shortening the testing cycle as rapid changes are released.

Of course, the out of the box user experience with Dynamic Data leaves much to be desired and is a little too simple for our needs so it requires some customization.  Once the customizations are done, they can be re-used over and over again but ONLY if they are written against a meta model so that they can apply to any entity on our model, not just coded against known entities, etc.

So what’s “Programming”?

In the normal case, programming is simply putting down the instructions required to make our applications work.  This still holds true in Dynamic Data and other “frameworks” … we are just walled into a set of constraints and conventions.

So what’s “Meta-Programming”?

In Dynamic Data, when creating customizations we have to interrogate the meta-data about the model and code against that instead of directly against the known model. We already have the Type object in .NET to discover much of what we need about the model (data type, field names, etc.) and we can enrich this model with attributes for information like descriptive names, validation rules and so forth.

This makes typical “programming” tasks more challenging starting with simple tasks like presenting the data on the screen to querying the data source without actually knowing the model ahead of time.  LINQ queries change from a simple query syntax to expression trees.  Once you get in the right mindset … it’s kinda of fun.

So what’s “Meta-Meta-Programming”?

This is where the real fun starts.  In Dynamic Data, we are using Model-First Entity Framework to essentially drive the entire application.  This generates the model, which we mark up with the metadata so we can “meta-program” around it.  But what if we can also generate the metadata?

By default, the Entity Object code generator creates decent classes which match the model, play nice in OOP and who’s persistence is managed though the generated ObjectContext. But there are lots of fields on the Entity Model which are largely untouched. What if we could “program” the entire application through the Model and with maybe a little side of metadata on the attributes?

To begin to accomplish this, we ditched the default code generation and downloaded (Nuget rocks) the EF5 Entity Object T4 template.  We then began to generate our metadata through addition fields on the model (DefaultValue, Is Nullable, Documentation).  So the T4 template with these additional fields become our meta-meta-programming tasks, we meta-program the UI to react to the metadata, and we toss in some good old fashioned programming when we get sick of expression trees and reflections.

I may write about the T4 template we created but just contact me if you want a copy in the meantime.