Your official information source from the .NET Web Development and Tools group at Microsoft.
In the previous post we looked at an overview of what is Model Binding and the benefits it brings in for WebForms developers. In this post we will look at the basic fundamentals and how the Model Binding system works with controls.
Uptil ASP.NET v4.0, data binding in controls happened with data bound controls such as GridView used to bound to data source controls such as ObjectDataSource. We will use this as a reference to understand the flow in the Model Binding System. A lot of the implementation derives inspiration from ObjectDataSource.
Following snippet shows how a GridView calls the Model Binding system to get a list of products.
<asp:GridView ID="getProduct" runat="server" ItemType="Products"
public IQueryable<Products> getProduct_GetData()
// The id parameter name should match the DataKeyNames value set on the control
public void getProduct_UpdateItem(int id)
Products item = null;
// Save changes here, e.g. MyDataLayer.SaveChanges();
At the heart of the Model Binding system is a datasource called ModelDataSource. and ModelDataSourceView As a developer when you never Bind the GridView to the ModelDataSource. The DataSource is an implementation detail which takes in value from the control and passes onto the ModelBinding system to perform the Binding & Validation to the model and gives the result back to the control/page.
Now that we know that there is a datasource involved at the implementation level of the ModelBinding system, let’s look at the flow from the control – ModelBinding – control. At a very high level this is what happens
I wanted to put this information out now so that you can get an idea about the plugability areas that exist in the ModelBinding system. In the later posts w We are going to look more into the details
The initialization of the ModelBindig system registers the following ModelBinders. These partition the responsibilities of the original DefaultModelBinder, making it easy to consume them from your own custom binder or to replace their individual responsibilities. For example, changing how dictionaries are bound application-wide now involves replacing a single provider rather than rewriting the DefaultModelBinder. The binders included in-box are, in order:
· TypeMatchModelBinderProvider – If the incoming value is already typed correctly for the target model (e.g. incoming value is string, property to bind is string), short-circuits the entire process and just returns the string.
· BinaryDataModelBinderProvider – Handles binding base-64 encoded input to byte and System.Linq.Data.Binary models.
· KeyValuePairModelBinderProvider – Handles KeyValuePair<TKey, TValue>. Consumed by the dictionary binder.
· ComplexModelDtoModelBinderProvider – Handles complex models. Consumed by the mutable object binder. More info on this type in the tutorial at the end of this document.
· ArrayModelBinderProvider – Handles T.
· DictionaryModelBinderProvider – Handles IDictionary<TKey, TValue>.
· CollectionModelBinderProvider – Handles IEnumerable<T>.
· TypeConverterModelBinderProvider – Handles simple type conversions, e.g. incoming value is a string and property to bind is an integer.
Following are the Value providers which you can use to specify where should the ModelBinding look for when trying to get the value
The value is retrieved from the Form collection
The value is retrieved from the specified control
The value is retrieved from the QueryString collection
The value is retrieved from the Cookie collection
The value is retrieved from the Profile collection
The value is retrieved from the Route collection
The value is retrieved from the Session collection
In the next few posts we will look at how to do basic create/replace/delete/filtering cases and then look at extending the ModelBinding system using these concepts
Hope you will find this useful!!!