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.

Data Binding with Model Binding

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"

            UpdateMethod="getProduct_UpdateItem"

             SelectMethod="getProduct_GetData" />

public IQueryable<Products> getProduct_GetData()

        {

            return _context.Products.ToList();

        }

        // The id parameter name should match the DataKeyNames value set on the control

        public void getProduct_UpdateItem(int id)

        {

            Products item = null;            

            TryUpdateModel(item);

            if (ModelState.IsValid)

            {

                // 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.

Page Execution Flow

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

• GridView calls the SelectMethod to get the values
• This initializes the ModelDataSource and it calls the ExecuteSelect method on ModelDataSourceView
• The ModelDataSourceView calls the DefaultModelBinder
• DefaultModelBinder looks through all the ModelBinderProviders registered in the system and tried to get the ModelBinder that can provide the value for a given Type
• The selected ModelBinder gets called to perform the Binding of values to the Model
• The ModelBinder calls the ValueProvider to get the value.
• This is useful if you want to specify that the value is coming from a control/querystring or other collections

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

Model Binders and Model Binder Providers

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.

Value Providers

Following are the Value providers which you can use to specify where should the ModelBinding look for when trying to get the value

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!!!