Lost In Tangent

When a MetaModel is initialized from a data source (via its respective provider), what additional information is determined in the process? The MetaModel itself contains a couple of useful instance properties and methods (more of which we’ll examine later), but for the purpose of this article, we only care about its Tables property, which is of type ReadOnlyCollection<MetaTable>. As you can imagine, that property returns a list of MetaTable instances that represent every entity in our underlying data source.

The MetaTable class contains a whole slew of useful properties that we otherwise couldn’t deduce from its respective model class, such as: ForeignKeyColumnNames, DisplayName, PrimaryKeyColumnNames and SortColumn. As you can see, because of the higher-level semantics provided us by the MetaModel, any controls within our UI, that are aware of the MetaModel, can now take advantage of these additional attributes. The MetaTable class also contains a Columns property, which is of type ReadOnlyCollection<MetaColumn>, and contains a list of every column/property in the entity.

The MetaColumn class is where the real meat of the metadata system lies. It contains loads of properties for gathering information about a column/property from its underlying model, such as: DefaultValue, IsGenerated, IsRequired, MaxLength, NullDisplayText and RequiredErrorMessage. In addition, a MetaColumn can be of type MetaChildColumn or MetaForeignKeyColumn if it participates in an association.

Why does any of this matter? Because this rich MetaModel, in conjunction with our actual data model, provides us with enough information about the structure/semantics of the data that we can begin deducing lots of functionality/behavior from it. Better yet, our UI can do that for us. It’s clear at this point that the only thing we need in order to begin developing smarter data-centric applications are UI frameworks that can understand and react to the contents of our MetaModel.

Before we move on to examining how Dynamic Data provides extensions to ASP.NET that allow our UI to make use of a MetaModel, we need to briefly address where the MetaModel is getting its contents from. How exactly does it know what the DefaultValue for a column is, or the DisplayName for an entity is? It simply asks the provider. If you’re using an Entity Data Model, its respective provider can scavenge metadata from the EDM; if you’re using a LINQ To SQL model, its respective provider can examine the MetaModel (yes L2S uses this term as well) for metadata; if you’re using any other datasource, then you can create a custom provider that can determine that information however it makes sense.

You may be thinking right now that neither an EDM nor a L2S model provide the full extent of metadata that I’ve highlighted our MetaModel as exposing, and you’d be exactly right. In addition to the providers looking at their datasource specific mediums for metadata, there is also a set of common data annotations that can be applied to your data model and will be picked up by the MetaModel. These annotations live in the System.ComponentModel.DataAnnotations assembly/namespace.

These annotations have absolutely nothing to do with Dynamic Data, and are meant solely for annotating model classes within data-driven applications. Dynamic Data just happens to be the first UI framework (technically ASP.NET is) that understands them and makes use of them. In the next article I’ll explain how to make use of these annotations.