In the previous article, I mentioned that the existing data controls in WebForms aren’t very smart as regards to your data, but in all fairness, it isn’t really their fault. How is a GridView supposed to know that a property is required? How can a FormView know that a specific control should include regular expression validation? How can a DetailsView know that certain columns shouldn’t be displayed? Since those controls are completely agnostic as to the type of data they are bound to, there is no set of common assumptions they can make about their bound data in order to provide a richer set of UI behaviors.
It almost seems like what we need is some sort of meta-model, that provides additional semantics/metadata on top of our data model that our WebForms controls can leverage to make the desired assumptions. That way, we could bind any type of data to the controls, and they wouldn’t have to rely on any specific model type, but could rather use the meta-model to determine the additional actions it should (or shouldn’t) take. Because the meta-model would have a common form, the controls would only have to be aware of a single metadata system.
While having a common metadata representation is great, how can a meta-model be created based on every possible type of data? Obviously that wouldn’t be practical to have a single codebase that determined metadata from every data type. Rather, what we’d need is the ability to create a provider that was aware of a specific data type and could create a meta-model from it. This way, allowing a new data type to work with our common metadata system would be as easy as creating a new provider.
The solution described thus far is exactly what Dynamic Data provides. A common meta-model system for describing data models with a higher semantic that a UI can leverage to be smarter by default. Out of the box, it includes providers for LINQ-To-SQL and the Entity Framework (which is why it has gotten a reputation for working solely against databases), but nothing stops it from working against any other data source. In fact, prototypes already exist that have Dynamic Data working against an ADO.NET Data Service, as well as a SQL Data Service.
So what does the code look like for creating a meta-model from an existing data model?
public class Global : HttpApplication { protected void Application_Start(object sender, EventArgs e) { var model = new MetaModel(); model.RegisterContext(typeof(AdventureWorksContext)); } }
In that code sample, “AdventureWorksContext” is the name of my ObjectContext (a generated class used for working with an Entity Data Model). It could have also been a DataContext (a class used for working with a LINQ To SQL model), and the MetaModel would have been created just fine. This is because the RegisterContext method is aware of L2S and EF models and will created the necessary provider to fill the MetaModel. What if your data source is something other then a L2S or EF model? Then you can just pass an instance of your custom provider to the RegisterContext method.
var model = new MetaModel(); model.RegisterContext(new ArbitraryDataModelProvider());
Your provider would then be responsible for traversing your data source and retrieving the metadata that described it. The first MetaModel that you create is considered the default instance, and is stored in the static MetaModel.Default property. MetaModels can also be retreived by type using the MetaModel.GetModel method (in case you have multiple). Once you’ve created your MetaModel during your application’s start event in the Global.asax file, your MetaModel is now globally available throughout your application, just waiting to be leveraged by your UI.
While this all seems dandy, two questions arise: what metadata does the MetaModel expose, and where did it get it from? I’ll cover those questions in the next article.
