Let’s pick up where we left off in the previous post. We had an ASMX service already in place for returning customer data. Using ASP.NET AJAX 4 we could create a DataContext that pointed at the service and associate it with a DataView to dynamically display all customers returned from the service. One thing that we didn’t mention is the DataContext’s saveOperation property. We could modify our previous example like so…

var dataContext = $create(Sys.Data.DataContext, { 
                               serviceUri: "Customers.asmx", 
                               saveOperation: "SaveCustomers" 
                          });       
 
var customersTemplate = $create(Sys.UI.DataView, { 
                            autoFetch: true, 
                            dataProvider: dataContext, 
                            fetchOperation: "GetCustomers", 
                            fetchParameters: { count: 10 } 
                        }, 
                        null, 
                        null, 
                        $get("customers-template"));

Notice that nothing has changed from the perspective of the DataView declaration. The only difference between the above sample and the read-only scenario we created in the previous post is the existence of the saveOperation property on the DataContext. Here we’re telling the DataContext that there is a method called “SaveCustomers” on our ASMX service that is responsible for handling the persistence of changes. When we call the saveChanges method on the DataContext, it will trigger a request to the save operation method, passing it a change set that represents all of the changes made to the local data since the last time it was saved.

Two questions arise here that need to be addressed before moving on:

1. How is it that changes are happening to the data coming back from the DataContext?
2. How is it that the DataContext can know which exact changes have happened when trying to persist them back to the server?

Remember in the previous post that I mentioned that the DataContext was basically a class that can connect to a server-side resource, as long as that resource serves JSON data? That technically isn’t true, since the DataContext could work just fine with services that return XML or other payload formats. The reason I limited the DataContext’s abilities is because the only type of data that it can provide change tracking on is JSON data, and since change tracking is the key feature of the DataContext, it should almost be viewed as a limitation.

The main value of services that return JSON data is that once that data is returned to the JavaScript client it can immediately begin using it since that data is represented by instances of objects, as opposed to XML that would need to be parsed. To answer the first question above, since the DataContext is retrieving JSON data from services, and JSON data is simply object instances in memory, changes can happen to the data as easily as modifying property values on the returned objects. But, if your using a DataContext simply to associate it with a DataView (or some other control), you’re not necessarily handling the returned data yourself, but rather, the DataView is. Let’s take a brief detour into client templates…

In all of the samples that I’ve been using thus far I’ve instantiated a DataView around an element called “customers-template”. What exactly is “customers-template”? It is an instance of a client template (another new feature in ASP.NET AJAX 4) that is responsible for displaying instances of customers. The customers client template, in our example, looks like this…

<table cellspacing="0">
    <thead>
        <tr>
            <th>Title</th>
            <th>First Name</th>
            <th>Middle Name</th>
            <th>Last Name</th>
            <th>Suffix</th>
        </tr>
    </thead>
    <tbody id="customers-template" class="sys-template">
        <tr>
            <td><input type="text" value="{binding Title}" /></td>
            <td><input type="text" value="{binding FirstName}" /></td>
            <td><input type="text" value="{binding MiddleName}" /></td>
            <td><input type="text" value="{binding LastName}" /></td>
            <td><input type="text" value="{binding Suffix}" /></td>
        </tr>
    </tbody>
</table>

What we have here is a template that represents a tabular display of customers, including the full name, title, and suffix. The part that represents the actual client template is the <tbody> element. Notice that the ID of the <tbody> corresponds to the ID of the element that is represented by the DataView control we created. What the DataView will do is ask its corresponding DataContext for data (which will call its respective service), instantiate an instance of its associated client template, and create an instance of the template for every instance of data that is retrieved from the DataContext. Hence, in our example, we will get a table row for every customer.

In order to actually interpolate data into the client template you use what are called bindings. ASP.NET AJAX’s bindings look very similar to those in WPF/SL, and are represented by the contents of the value attributes of the <input> elements in the example above. Bindings are a fairly complex topic that I won’t get into it this post, but for the sake of our sample you can think of bindings as being able to synchronize two property’s values together. In this case, we’re synchronizing the value property of the textboxes to individual properties of the customer objects (remember that we’re getting back JSON data, which includes properties for all of the customer’s assets).

If we were to run this sample as is right now, we’d get something like this (I have some basic CSS in place as well)…

As expected, we have a table with a row for each customer, and the customer’s name, title, and suffix are bound to individual textboxes. This is great for read-only scenarios so far, but since we’re using textboxes for this display, it would be great to be able to edit the customer data and push it back to the server. Because we used bindings to attach the textbox values to customer properties, when you modify the value of any of the textboxes in this table you’re also modifying the value of its respective customer object. This is a very subtle but very powerful feature of client templates and bindings. This also answers our question of how you can go about changing your data when using it in conjunction with a DataContext and DataView.

Let’s move on to the second question of how it is the DataContext can know about the changes. The act of binding data to controls is by no means anything new. Binding a customer to a row, and then each of its properties to textboxes is a pretty basic act. But, what we really need, is for each of the individual customer instances to be able to report back to their “parent” DataContext when they’ve changed. If I go up into the form above and enter “Sr.” into the Suffix textbox for Orlando Gee, I need that customer instance that represents Orlando Gee to notify the DataContext that he has changed. That way, whenever I call the DataContext’s saveChanges method, it would already know what changes have happened and can send them to the service.

If you were using WPF or WinForms or Silverlight, you would have to make your Customer class implement an interface called INotifyPropertyChanged. The whole purpose of this interface is to make objects capable of notifying some interested party when it has changed. This approach works alright but it is also painful and is frankly a gleaming example of the constraints of statically typed languages. JavaScript is a dynamic language and as such we shouldn’t be held down by such limitations. But the need still exists to have our customer objects report their changes back to the DataContext. How will that happen?

Attention: this entire paragraph is very key…whenever the DataContext is used to retrieve data from a service, it will automatically inject every JSON instance with the necessary logic so that it can report any changes back to the DataContext. The above example would flow something like this…

1. The DataView asks its associated DataContext for data
2. The DataContext requests its associated service for the data, and once retrieved injects the objects with change tracking behavior
3. The DataView then creates an instance of its associated client template for every instance of data it received from its DataContext and binds the data instance to the client template instance
4. If you modify data through the client template UI (i.e. a textbox), since the JSON object instance is bound to the UI, and the JSON objects contain change tracking logic, those changes will trigger a notification to the DataContext letting it know all of the changes
5. When you call DataContext.saveChanges, it already knows about every change that has happened (by virtue of the binding notifications), and can simply send that change set to the service
6. The DataContext will then call the service method specified in the “saveOperation” property, passing the change set

What this means is that you don’t have to worry about change tracking or data synchronization at all,  which is great because those are two of the most painful parts of developing data-driven applications (in my opinion). On the service-side you simply need to create the corresponding method to receive the save operation. For our ASMX service it could look like this…

[WebMethod] 
public void SaveCustomers(List<Change<Customer>>> changeSet) 
{ 
    // Save the customer data 
}

The Change class is a simple container class that wraps the data instance that was changed and the change that occured (e.g. Insert, Update, Delete). Within that service method we can now take the appropriate actions to persist the changes based on whatever our data store is.

While ASMX and WCF provide a great option for general-purpose services, if what you need is a service for the sole purpose of retrieving and persisting data then using either ASMX or WCF is a roundabout way to go. ADO.NET Data Services should be seen as the defacto option for data-centric services since it does most of the heavy lifting for you. In fact, if you’re using a DataContext with a DataView and a Data Service (that’s a lot of data stuff) then you don’t have to do anything extra in order to persist your changes. Data Services automatically includes the logic to receive a change set and push it back to your data store, which alleviates the need to create a save operation.

So what is the moral of the story? The DataContext class can be used for read-only service interaction, but truly shines when you need automatic change tracking and unit of work behavior. You can use the base DataContext class when working with an RPC-style service (i.e. ASMX/WCF), but in most cases, if you’re developing a data-centric application, using the AdoNetDataContext along with an ADO.NET Data Service is going to provide you with a much easier solution. The DataContext works beautifully with a DataView and allows you to create dynamic data-driven UI, that when used with live bindings, can provide a really compelling user experience.

There is though still an outstanding question here: what if you’re using ASP.NET MVC and you want to leverage controllers to handle all incoming requests? There are plenty of scenarios where you don’t want to have to create an ASMX/WCF/Data service just to provide data to an AJAX client, when your controllers are perfectly good for that (in fact you could argue that in a “true” MVC application, the whole point of the controller role is to intercept user interaction, so using another service type is slightly awkward). Remember in the last post how I mentioned that the DataContext was also a great foundation for creating more specific context’s for additional scenarios? In the next post I’ll show how we created a DataContext that provides full change tracking and persistence when using ASP.NET MVC.

[ScriptService] 
public class CustomersAsmx : WebService { 
    private CustomersContext context = new CustomersContext(); 
 
    [WebMethod] 
    public Customer[] GetCustomers(int count) { 
        var customers = (from cus in context.Customers 
                         orderby cus.Id 
                         select cus) 
                         .Take(count) 
                         .ToArray(); 
 
        return customers; 
    } 
}

Calling that service using a DataContext might looking something like this…

var context = $create(Sys.Data.DataContext, { serviceUri: "Customers.svc" }); 
context.fetchData("GetCustomers", // Operation name 
                  { count: 10 }, // Operation parameters 
                  Sys.Data.MergeOption.overwriteChanges, // Merge-option (optional) 
                  "POST", // HTTP verb (optional) 
                  function customerFetchSuccess(customers) { 
                      // Do something with customers... 
                  }, 
                  function customerFetchFailure(error) { 
                      // Handle the error somehow... 
                  });

As you can see, there are all kinds of options that can be passed to the fetchData method, many of which are optional. The above scenario makes use of an ASMX service, but you could just as easily be targeting an AJAX-enabled WCF service, which both have pretty similar semantics in this scenario.

What if you’re using ADO.NET Data Services though? In theory, since the DataContext class can make requests against any service that responds with JSON data (which Data Services can do), it should be able to consume a Data Service with a few modifications to the above code sample…

var context = $create(Sys.Data.DataContext, { serviceUri: "Customers.svc" }); 
context.fetchData("Customers", 
                 { $top: 10 }, 
                  null, // Defaults to overwrite changes 
                  "GET", 
                  function customerFetchSuccess(customers) { 
                      // Do something with customers... 
                  }, 
                  function customerFetchFailure(error) { 
                      // Handle the error somehow... 
                  });

Obviously the serviceUri property now points at a Data Service instead of an ASMX/WCF service, but the real points of interest lie in the operation/parameters. While ASMX and WCF are traditionally operation-centric services (see note below), ADO.NET Data Services is resource-centric, and doesn’t have methods that we can target (unless of course you’re using service operations). Hence, to consume the Data Service from our DataContext, we set the operation method to the name of the resource set (i.e. Customers) that we want to retrieve. Operation parameters work the same as with ASMX/WCF, but since Data Services has its own predefined set of query options, we simply need to comply with them (i.e. using $top). Finally, Data Services uses the GET HTTP verb for all data read requests (as opposed to traditional RPC style services that use POST for everything), so we need to set that.

By default, WCF leans towards the edge of RPC-style/SOAP services, but is capable of providing REST-style services that are resource-oriented. An ADO.NET Data Service is itself a WCF service that exposes a RESTful interface and makes data-centric services really easy to implement and consume.

If you ran the above sample, it would work, but not exactly as you might like. The customers data that is passed into the success callback would be a string of XML, representing the AtomPub feed sent back from the Data Service. The reason for this is because ADO.NET Data Services will by default serve its data as AtomPub. If a request comes in that includes the Accept HTTP header set to “application/json” then the Data Service will return JSON data. Unfortunately the DataContext class doesn’t set the Accept header when making service calls, which makes consuming a Data Services from it pretty sub-optimal.

You might be thinking to yourself: “Hey that’s cool, I’ll just grab the request that is associated with the DataContext and add the Accept header myself!”. Unfortunately that isn’t possible since the DataContext doesn’t expose its underlying request. If you’re a seriously hardcore ASP.NET AJAX dev, you might be thinking: “Alright fine, I’ll just use the WebRequestManager to tap into the request before it’s sent”. That is totally possible, and would look something like this…

Sys.Net.WebRequestManager.add_invokingRequest(function(sender, args) { 
    var request = args.get_webRequest(); 
    request.get_headers()["Accept"] = "application/json"; 
});

Unfortunately that solution is ridiculously unintuitive and is now intercepting all requests just to accommodate a single case. Unless you have a really good reason you should almost never do this. How then can we use a DataContext to easily consume a Data Service? Well, you can’t use the DataContext per se, but you can use a subclass of it, like so…

var context = $create(Sys.Data.AdoNetDataContext, { serviceUri: "Customers.svc" }); 
context.fetchData("Customers", 
                 { $top: 10 }, 
                  null, // Defaults to overwrite changes 
                  null, // Defaults to GET 
                  function customerFetchSuccess(customers) { 
                      // Do something with customers... 
                  }, 
                  function customerFetchFailure(error) { 
                      // Handle the error somehow... 
                  });

Notice that we’re now using an AdoNetDataContext instead of the vanilla DataContext. This immediately does two interesting things for us: defaults the HTTP verb to GET (as opposed to POST), and sets the Accept header to “application/json” for us (so the Data Service will return JSON data instead of XML). Now if we ran the above code, we would successfully get back the top ten customers as JSON objects.

The DataContext class should be viewed as two things:

1. An easy solution for consuming RPC-style services (i.e. ASMX or WCF)
2. A great foundation for other higher-level service clients

If your server-side resource is an ASMX or WCF service then the basic DataContext is exactly what you want and will work seamlessly. If however you’re using an ADO.NET Data Service, then the DataContext lacks the semantics you need to work successfully, and you should use the AdoNetDataContext instead. If you want to consume some other service type that requires some special attention, you could also choose to subclass DataContext and add on the extra behavior you need (it honestly is pretty simple to do).

Hopefully some of you are reading this and thinking that I’m absolutely crazy to think you would use a DataContext just to retrieve data. The above code sample for consuming an ASMX service could be achieved using a class that has been in ASP.NET AJAX since its conception (WebServiceProxy), and doesn’t require us to create an instance (um, because it’s “static”)…

Sys.Net.WebServiceProxy.invoke("Customers.asmx", // Service URI 
                               "GetCustomers", // Operation name 
                               false, // Use GET 
                               { count: 10 }, // Parameters 
                               function customerFetchSuccess(customers) { 
                                  // Do something with customers... 
                               }, 
                               function customerFetchFailure(error) { 
                                  // Handle the error somehow... 
                               });

Notice that this code is nearly identical to what we wrote when using the DataContext, but we’ve removed the need to $create anything. There also happens to be an AdoNetServiceProxy class as well that enables you to make service calls to a Data Service, similarly to how we achieved it above. So the question arises: why on earth would you ever use a DataContext vs. just using its respective service proxy? There are two reasons:

1. You need an abstraction over your underlying request/proxy type
2. You need unit of work behavior, complete with automatic change tracking

The first part is important because the WebServiceProxy and AdoNetServiceProxy are drastically different and don’t share a common base class (er prototype). This becomes problematic when you have other classes that need to consume data, but don’t want to be tied to a specific service type. A great example of this is the new DataView class, which allows you to create dynamically-templated UI. The DataView has a property called “dataProvider” that accepts a DataContext, and uses that context to handle populating its templates with the data it needs. We can now hand the DataView any DataContext subtype we want and it will be able to consume the data without a care in the world…

var dataContext = $create(Sys.Data.AdoNetDataContext, { serviceUri: "Customers.svc" }); 
var customersTemplate = $create(Sys.UI.DataView, { 
                            autoFetch: true, 
                            dataProvider: dataContext, 
                            fetchOperation: "Customers", 
                            fetchParameters: { $top: 20 } 
                        }, 
                        null, 
                        null, 
                        $get("customers-template"));

I’ll save the gritty details of the DataView for another post. One point of interest though is that because we’re no longer manually calling DataContext.fetchData (because the DataView is doing that for us), the operation and parameters properties are now set on the DataView instead of the DataContext. This scenario is probably the most common usage of the DataContext, and illustrates how simple using a DataContext can be.

The second point made above was slipped covertly under the radar, but really should have been highlighted as being the major reason of why you would ever use a DataContext in the first place. The abstraction is nice but isn’t nearly compelling enough to warrant introducing an entirely new concept into your life. The DataContext is valuable because it provides you a unit of work experience. Up to this point I’ve purposely shown it being used for read-only scenarios, but it is so much more.

If you are looking to simply retrieve data from a service, you should use one of the proxy types (i.e. WebServiceProxy or AdoNetServiceProxy). In fact I would go so far as to say that if you find yourself manually calling the DataContext’s fetchData method, you are probably doing something wrong. If however you need to change the retrieved data, and then persist those changes back to the server, a DataContext is your best friend.

What if I told you that the code samples above that used a DataContext with a DataView will automatically provide change tracking and can save any changes back to the server as easy as a single line of code…

dataContext.saveChanges();

What subtleties exist with change tracking/persistence when working with DataContexts of different types? How exactly could such rich functionality be achieved with a single line of code? I’ll cover that aspect of the DataContext in another post…

Check out this new feature in action over at Channel 9: http://channel9.msdn.com/shows/10-4/10-4-Episode-14-Sentient-DSLs/. As always, I’d love to get your feedback on how useful you think this could be to you.

At first glance, you might think this is an easy problem to solve, and in some instances you’d be right, but the devil is most certainly in the details (as in figuring out quantum physics!). If you’re looking to be able to handle an infinite number of different data types, and generically interpret any possible form of input, then you’ve got quite a serious problem on your hands.

Thankfully this problem ends today. In addition to developing the recently released ASP.NET MVC framework, Phil Haack and Eilon Lipton have also been hard at work addressing the global issue of string input handling and quantum entanglement. This afternoon, the first public CTP of the new “String Input Handling Framework” (name pending) has been released. As much as I’d love to go on about how to use it, and how integral it will become in all future .NET development, Eilon has already put together a great blog post on this subject.

All I can say is: with innovative solutions like this under Microsoft’s belt, there is no question just how superior the .NET Framework is to everything else on the market. Move over Ruby, PHP, Python, Java, and everyone else (you know who you are), the .NET train is coming through, and we’ll be accepting any input you’ve got to throw at us!

Within the .NET 3.5 SP1 release, the initial consumer of Dynamic Data (and the newly introduced data annotations) was ASP.NET WebForms. This means that if you’re developing a data-driven web application, and your weapon of choice is WebForms, then you just happen to be in luck. Work is already underway to introduce some of Dynamic Data’s behavior into ASP.NET MVC that is appropriate to its style of development, and you can expect to see additional UI frameworks taking advantage of its semantics and data annotations as well in the near future.

So, the question becomes: now that I’ve got my data model, and I registered it with a MetaModel, how can I begin taking advantage of it within a WebForms application? Since it is the MetaModel that contains all of the metadata and validation, as well as the shape of our underlying data model, reason would lead us to believe that we’d need some type of server-control that was aware of a MetaModel and is ready to allow it to affect its behavior.

If you were to begin developing a data-centric WebForms application today, what are your options as far as server controls go? There’s actually a pretty rich arsenal of controls that can get you up and running pretty quickly, without having to sacrifice functionality…

All of those controls are awesome in their own way but they don’t exactly help us in our current endeavor. Not a single one of them has a clue what a MetaModel is or is really conscious of what being “data-driven” means. They support the notion of metadata and validation, but we have to explicitly define that information, instead of them deriving it from our data model.

While these controls lack some of the functionality we require we certainly don’t want to have to introduce a whole new suite of controls that we have to learn just to enable data-centric applications. What would be ideal is if we could extend or enhance the functionality that these controls already have to make them more fully-featured and MetaModel-aware. Luckily this is exactly what Dynamic Data provides, in the form of the following controls:

1. DynamicField
2. DynamicControl
3. DynamicControlParameter
4. DynamicQueryStringParameter
5. DynamicDataManager
6. DynamicValidator
7. FieldTemplateUserControl

While these new controls provide a lot of the functionality we’ll need, there is still one piece left to complete our little journey towards data-driven utopia: field-level templates. Since our focus is on the data in our application and the metadata that is associated with that data, a lot of times we might want to allow the presentation framework to determine how to render portions of our data automatically based on the structure of the data model, or better yet, the MetaModel.

These field-level templates could define the UI desired to display data of different types. This would allow us to determine how we wanted numbers, string, dates, etc. to look, in a single location, and have those templates leveraged throughout our entire application. Regardless whether we were creating tabular or form-based data entry forms, we could take advantage of the same templates, providing a consistent look and feel that is completely driven from our data model.

The FieldTemplateUserControl is what makes this functionality possible, and will be the focus of the next article. We’ll cover how it can be used to define custom field templates, as well as what field templates are provided out-of-the-box by Dynamic Data. Finally, we’ll cover how to wire-up your defined field templates to actually be used with your created MetaModel, effectively completing the field-level templating story (which is one of two possible scenarios provided by Dynamic Data).

We can all agree that the term “model” is pretty overloaded and has many different meanings/interpretations. You have domain models, presentation models, view models, super models, model trains, and so forth and so on. This series isn’t tied to any specific model implementation methodology per se, but rather on the intent of creating web applications that are focused around data in a RAD fashion. Because there are numerous ways of constructing an object model, we’d need a mechanism for discovering metadata from models that assume different shapes.

If you hand-craft your object model and perform the database-mapping yourself you could easily place data annotations on your entity classes and go on with it (as you might do if using NHibernate). While that is a totally valid scenario, it isn’t necessarily the right one for a data-driven application where you most likely already have a database in place and are looking to reverse engineer a model from it’s schema. For cases like that you might use something like LINQ To SQL or the Entity Framework, both of which provide designers/wizards for generating a mapped model to an existing database.

If I create a new Entity Data Model and point its wizard at an AdventureWorks database, I’ll end up with a whole bunch of generated entity classes that look something like this:

[global::System.Data.Objects.DataClasses.EdmEntityTypeAttribute(NamespaceName="AdventureWorks", Name="Address")] 
[global::System.Runtime.Serialization.DataContractAttribute(IsReference=true)] 
[global::System.Serializable()] 
public partial class Address : global::System.Data.Objects.DataClasses.EntityObject 
{ 
    ... 
}

Because that class lives within the confines of my EDMX, which is template-generated code, I don’t exactly want to go mucking around in there. If I later make a change with the designer, it would wipe out any changes I manually made to the entity classes, which would lead to a lot of pain and frustration. Luckily though, the entities are generated as partial classes which means we can make modifications to them from outside of the EDMX’s code files. This gives us the ability to leverage the designer and still have some level of flexibility over the codebase moving forward.

I can easily create a new partial class for my Address entity and begin placing some data annotations on it. Let’s say that I want to specify that the display name for it should be “Customer Address” and that the column (property) that should be used to represent it’s display value should be “Country”. I could easily do this:

[DisplayColumn("Country")] 
[DisplayName("Customer Address")] 
public partial class Address 
{ 
}

Because we’re using partial classes (which are combined at compile time), we’re still annotating the entity class itself, just using a different approach. We could easily retreive this metadata using standard reflection without requiring the need for a custom type descriptor. But what if I wanted to add metadata to one of the properties of my Address entity now? Let’s say that I wanted to specify that the Address2 property is required (even though it isn’t at the database level), PostalCode should be constrained by a regular expression, and that CountryRegion’s display name should just be “Country”. Because I don’t want to mess with the generated code of the EDMX I can’t go place data annotations directly on those properties. I definitely can’t do the following, since that would be declaring the properties twice on the same class:

[DisplayColumn("Country")] 
[DisplayName("Customer Address")] 
public partial class Address 
{ 
    public string Address2 { get; set; } 
    public string CountryRegion { get; set; } 
    public string PostalCode { get; set; } 
}

It might seem like we’re out of luck at this point and have to settle with changing the generated EDMX code. What if though, we could create a class whose sole purpose was to contain properties that we could annotate with metadata for another entity and then associate the two together? That would get us the functionality we need and work around the “issue” we’re dealing with between partial classes and generated code. Let’s say we created the following AddressMetadata class:

private class AddressMetaData 
{ 
    public string Address2 { get; set; } 
    public string CountryRegion { get; set; } 
    public string PostalCode { get; set; } 
}

We don’t get any compiler errors (obviously) so we’re moving in the right direction. How can we then associate this new type with our original Address entity class?

[MetadataType(typeof(AddressMetaData))] 
public partial class Address 
{

Now we can place any entity-level metadata on our Address partial class, and any property-level metadata on our new AddressMetaData class, because the two are associated. You can place/name your metadata type anywhere you want, but I prefer to make it a private/embedded class of the partial entity class itself. I can now add the metadata I want to my properties.

[DisplayColumn("Country")] 
[DisplayName("Customer Address")] 
[MetadataType(typeof(AddressMetaData))] 
public partial class Address 
{ 
    private class AddressMetaData 
    { 
        [Required] 
        public object Address2 { get; set; } 
 
        [DisplayName("Country")] 
        public object CountryRegion { get; set; } 
 
        [RegularExpression(@"\d{5}(-\d{4})?")] 
        public object PostalCode { get; set; } 
    } 
}

Notice that I changed the type of the three properties to “object” because the property type no longer matters. Within the metadata type, we only need to be concerned with naming the property correctly.

We established that standard reflection could handle the discovery of the entity-level metadata, but now that we’ve created this “metadata type” which has its own set of properties and metadata, reflection would have no clue of its semantic association with the Address entity. This is where the AssociatedMetadataTypeTypeDescriptionProvider comes in.

The AssociatedMetadataTypeTypeDescriptionProvider class is capable of looking at a type and finding any of its class-level attributes as well as looking to see if that type has an associated metadata type (via the MetadataType attribute) and if it does, grabbing any metadata from the metadata type’s properties. This is a fairly roundabout approach, but it gets us around in the meantime. In the future you might see the notion of “partial properties” that would remove the need for the metadata type altogether.

So now it’s clear why the AssociatedMetadataTypeTypeDescriptionProvider exists and is the default behavior. If our model is able to apply all metadata directly to the entity classes, then it will work great. If our model requires the use of a “associated metadata type”, then it will also pick up on that as well. If we had an alternate style of model, that required a different type of metadata discovery, then we could implement a TypeDescriptionProvider and set it via the ContextConfiguration’s MetadataProviderFactory property. Dynamic Data uses the specified provider throughout its entire API, making it extremely easy to swap our your model metadata discovery logic.

Now that we’ve got our model created and we’ve begun adding metadata to it, how can we start seeing the fruits of our labor take effect within our web application’s UI? In the next article I’ll begin showing how Dynamic Data provides a set of extensions to ASP.NET that can take advantage of your annotated models and the MetaModels derived from them.

Without a standard approach for adding metadata to data models (of any kind), data-driven UI frameworks would have a hard time providing the rich functionality we are demanding from them. By introducing the MetaModel, we’ve given the UI layer a robust view of the underlying data model such that it can provide the behavior we expect, so that problem is already solved. Now we just need a mechanism for annotating our model with metadata in such a way that our MetaModel can pick it up.

The .NET Framework 3.5 SP1 release contained an assembly named System.ComponentModel.DataAnnotations. Within that assembly is a collection of attributes that are meant to be associated with data models for the purpose of adding additional metadata and validation to them in a way that is agnostic to any specific UI framework. Notice that the namespace they live in isn’t “System.Web.*” or “System.Windows.*” but rather “System.ComponentModel.*”, which adds to the argument of standard use.

Because these data annotations are simply attributes, we can easily begin attaching them to our entity classes and properties, which adds additional information to our model such as validation constraints (range, regular expression, string length, etc.) and higher level semantics (data type, UI hint, scaffolding, etc.). The question is: how does our MetaModel discover these annotations once we’ve placed them on our model?

[DisplayColumn("FirstName", "LastName")]
public class Customer
{
    [Required]
    public string FirstName { get; set; }
 
    [StringLength(20)]
    public string MiddleName { get; set; }
 
    [Required]
    public string LastName { get; set; }
 
    [Range(18, 30)]
    public int Age { get; set; }
}

For any DDD proponents, I realize the above model class would be considered anemic. It’s important to keep in mind that the methodology being employed in this series is that of data-driven applications not domain-driven.

When you register a context/provider with a MetaModel (as we saw in a previous post), an instance of type ContextConfiguration is created and associated with your model. You can either explicitly create a ContextConfiguration instance and use one of the overloaded versions of the RegisterContext method that accepts one, or you can allow the MetaModel to create one for you. ContextConfiguration is an extremely simple class that contains only two properties: ScaffoldAllTables and MetadataProviderFactory. The ScaffoldAllTables property is only applicable if you’re leveraging Dynamic Data for full-blown scaffolding, which is a scenario we’ll touch on later.

// Implict ContextConfiguration...
var model = new MetaModel();
model.RegisterContext(typeof(AdventureWorksContext));
 
// Explicit ContextConfiguration...
var model2 = new MetaModel();
model2.RegisterContext(typeof(AdventureWorksContext),
                      new ContextConfiguration { ScaffoldAllTables = false });

The ScaffoldAllTables property defaults to false, so if we aren’t concerned with Dynamic Data’s scaffolding behavior (which in this case we aren’t), we can just omit that property instead of explicitly setting it.

The MetadataProviderFactory property is of type Func<Type, TypeDescriptionProvider>, which might look scarier than it actually is. Func is simply a generic delegate that returns a value and optionally takes up to four parameters (there are five variations of Func). In this case we’re dealing with a Func that will accept a parameter of type Type and return an object of type TypeDescriptionProvider. When we register a context/provider with a MetaModel, it will enumerate through every entity type in our model, calling the delegate within the ContextConfiguration’s MetadataProviderFactory property, which will then return an TypeDescriptionProvider.

model.RegisterContext(typeof(AdventureWorksContext),
                       new ContextConfiguration
                       {
                           MetadataProviderFactory = (type) => new CustomTypeProvider()
                       });

A TypeDescriptionProvider is (as you can probably guess) responsible for providing a type descriptor (more specifically an object that implements ICustomTypeDescriptor or inherits from CustomTypeDescriptor). An ICustomTypeDescriptor implementation is able to determine information about a type such as its properties, events, attributes, etc. This allows applications to use a type descriptor to retrieve metadata about a type instead of using reflection directly. Why is this useful? Because you could create a custom ICustomTypeDescriptor that represented the shape of a type differently then it is in code.

As was mentioned above, the standard data annotations are provided as attribute classes, so the fact that a type descriptor allows you to retrieve attributes from a type (as well as that type’s properties), makes it very useful. By being able to create a custom TypeDescriptionProvider we can effectively implement logic that retrieves our model metadata from any source (i.e. XML, database, etc.), but uses the same standard data annotations, giving us both consistency and flexibility.

If you don’t explicitly set the MetadataProviderFactory property, the Metamodel will internally create an instance of the AssociatedMetadataTypeTypeDescriptionProvider class (that is a hell of a name!). This TypeDescriptionProvider implementation simply retrieves all attributes for a type via reflection. Why is this any better than just using reflection directly? Because it also retrieves any attributes from the requested type’s associated metadata type as well.

What exactly does “associated metadata type” mean? And why is it beneficial that the TypeDescriptionProvider be able to retrieve its attributes? We’ll discuss these two questions and expand on the usage of data annotations in the next article.

The majority of these albums are post-rock, electronic and instrumental artists. There are a few metal, indie, folk and post-hardcore albums as well. I did a TON of traveling this year and this is the collection that kept me sane around the world. If you care for a more “formal” list, you can check out my other site, The Silent Ballet, in a few weeks.

1. Helios - “Ceasura” (Link)
2. Lights Out Asia - “Eyes Like Brontide” (Link)
3. Shearwater - “Rook” (Link)
4. No.9 - “Usual Revolution And Nine” (Link)
5. Sumner McKane - “What A Great Place To Be” (Link)
6. Suffocate For Fuck Sake - “Blazing Fires And Helicopters On The Front Page Of The Newspaper. There’s A War Going On And I’m Marching In Heavy Boots” (Link)
7. Bersarin Quartett - “Bersarin Quartett” (Link)
8. This Town Needs Guns - “Animals” (Link)
9. Jóhann Jóhannsson - “Fordlandia” (Link)
10. Cult Of Luna - “Eternal Kingdom” (Link)
11. This Is Your Captain Speaking - “Eternal Return” (Link)
12. Up-C Down-C Left-C Right-C ABC + Start - “Embers” (Link)
13. Balmorhea - “River Arms” (Link)
14. Strangers Die Every Day - “Aperture For Departure” (Link)
15. Takahiro Kido - “Fleursy Music” (Link)
16. M83 - “Saturdays = Youth” (Link)
17. Mouth Of The Architect - “Quietly” (Link)
18. Lakes Of Russia - “Stars Decorate The Fire” (Link)
19. Earth - “The Bees Made Honey In The Lion’s Skull” (Link)
20. Fuck Buttons - “Street Horrrsing” (Link)
21. The Drift - “Memory Drawings” (Link)
22. Beneva Vs. Clark Nova - “Sombunall” (Link)
23. Mooncake - “Langrange Points” (Link)
24. We’re From Japan! - “Now Breath” (Link)
25. The Evpatoria Report - “Maar” (Link)
26. Arms & Sleepers - “Black Paris 86″ (Link)
27. d_rradio - “d_rradio” (Link)
28. Gregor Samsa - “Rest” (Link)
29. Russian Circles - “Station” (Link)
30. Ef - “I Am Responsible” (Link)
31. Pg.Lost - “It’s Not Me, It’s You!” (Link)
32. Neil On Impression - “L’oceano Delle Onde Che Restano Onde Per Sempre” (Link)
33. He Can Jog - “Middlemarch” (Link)
34. The Seven Mile Journey - “The Metamorphosis Project” (Link)
35. Goodnight, Sleep Well - “The Recovery” (Link)
36. Kyte - “Kyte” (Link)
37. Unwed Sailor - “Little Wars” (Link)
38. Daturah - “Reverie” (Link)
39. Port Blue - “The Albatross” (Link)
40. My Education - “Bad Vibrations” (Link)
41. Build - “Build” (Link)
42. God Is An Astronaut - “God Is An Astronaut” (Link)
43. MGMT - “Oracular Spectacular” (Link)
44. Lindstrøm - “Where You Go I Go Too” (Link)
45. September Malevolence - “After This Darkness, There’s A Next” (Link)
46. The Absent Sound - “Gathering Of The Clan Mothers” (Link)
47. The Calm Blue Sea - “The Calm Blue Sea” (Link)
48. Beast, Please Be Still! - “Beast, Please Be Still!” (Link)
49. Robin Guthrie - “3:19 Bande Originale du Film” (Link)
50. Peter Broderick - “Float” (Link)

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.

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.