For the ASP.net developer MVC not less then a magic. In asp.net developer develop the page and hit the page and request for the page for that page and server send response for that page (I am not going in to detail for ASP.net handler as we are talking about MVC magic).
It look like a magic because of the
1)The way we are accessing the MVC page (View)
2)The way data pass to the controller
most of Developer aware with all the asp.net page life cycle. Let 's take look of MVC life Cycle
There are two MVC component perform the magic
1)MVCRouteHandler
2)MVCModelBinder
1)MVCRouteHandler
The ASP.NET Routing module is responsible for mapping incoming browser requests to particular MVC controller actions. By the end of this tutorial, you will understand how the standard route table maps requests to controller actions.
The default route handler is already define in Globle.aspx as bellow
public class MvcApplication : System.Web.HttpApplication
{
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" } // Parameter defaults
);
}
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
}
}
When an MVC application first starts, the Application_Start() method is called. This method, in turn, calls the RegisterRoutes() method. The RegisterRoutes() method creates the route table.
The default route table contains a single route (named Default). The Default route maps the first segment of a URL to a controller name, the second segment of a URL to a controller action, and the third segment to a parameter named id.
Imagine that you enter the following URL into your web browser's address bar:
/Home/Index/3
The Default route maps this URL to the following parameters:
controller = Home
action = Index
id = 3
When you request the URL /Home/Index/3, the following code is executed:
HomeController.Index(3)
The Default route includes defaults for all three parameters. If you don't supply a controller, then the controller parameter defaults to the value Home. If you don't supply an action, the action parameter defaults to the value Index. Finally, if you don't supply an id, the id parameter defaults to an empty string.
Let's look at a few examples of how the Default route maps URLs to controller actions. Imagine that you enter the following URL into your browser address bar:
/Home
Because of the Default route parameter defaults, entering this URL will cause the Index() method of the HomeController class in Listing 2 to be called.
In this way MVC identify which controller action to be invoke and which view to be rander
2)MVCModelBinder
The model binder takes a set of value providers, model metadata providers and validator providers and creates the objects in the parameters of your action methods, performs validation, and the resulting objects are passed in as parameters when the action method on the controller is invoked. That is how a form post can become a fully hydrated and validated object before you do anything explicitly in your controller. If you did not know it did all of that, well, pay attention because there is some interesting stuff ahead.
Will start with an example action method on a controller.
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult AFormPost(string aSimpleType,
ACoolModel aComplexType)
{
//Do whatever...
}
Let us say that this action method would be found on your site at http://foo.com/home/aformpost and you are posting to that url. The class in the framework that is responsible for calling the method above is called the ControllerActionInvoker (which you do not need to be too concerned about remembering as you do not use it directly). When the route is parsed by the runtime, that is the class that is responsible for calling an appropriate method on a controller. The ControllerActionInvoker sees that the action method has two parameters that it has to supply. To do that it uses the DefaultModelBinder to attempt to interpret the values available and force them into one of the two parameters specified. And where does it get its values? What are the available sources? Well, it looks in this order:
The form values.
The route data.
The query string.
The http file collection.
These are called the "value providers". If it finds a value in the first provider, it will pull it from the first. If not, the second, and so on. It will look by name, so if you had a parameter named "foo" and a text input field also named "foo", it would match based on that. And it is not case sensitive.
In the case of the first parameter in the example above, it will see that it is a simple model (like string, int, et al., as opposed to a complex model, which would be one defined by a separate class such as ACoolModel above) and will convert it to that type and assign it to the parameter.
In the case of the second parameter, it will see that it is not a simple model and will instantiate an instance, figure out the properties, and for each one look in the value providers to find a value to assign to the property.
In either case, if the assignment fails because of type conversion errors or the like, an error is added to the ModelState (the thing responsible for keeping track of the validation state of the model). The DefaultModelBinder will then look for any validators on the property and check those. If validation fails, an error will be added to the ModelState. More on validation and model state in the next tutorial.
So that is the basics of the model binder. By creating your own model binder you can take complete control of the process. However, I have found that the default model binder works almost all of the time, but we will discuss how to create your own model binders at a later time.
In summary, the model binder takes a set of value providers and creates the objects in theparameters of your action methods, performs validation, and the resulting objects are passed in as parameters when the action method on the controller is invoked. That is how a form post can become a fully hydrated and validated object before you do anything explicitly in your controller.
reference:
