Model Binder workflow and Extension Method of Asp.net MVC (1)

In Asp.net MVC, Model Binder is a very important part in the lifecycle. The process of Model Binder can help you understand what happened behind Model Binder. In addition, this series of articles lists the extension points of Model Binder in MVC and how to use these extensions. Reading Directory: 1. workflow 2 of Model Binder in MVC. inherit IModelBinder and implement CustomeBinder 3. disadvantages of using Custom Model Binder 4. conclusion 1: the workflow of Model Binder in MVC is in MVC. When a request is sent to the server, it must first go through Route matching, find the corresponding Controller and Action, and then construct the parameters in the Action, that is, the process of Model Binder can be seen from the MVC source code, ControllerActionInvoker. Blog-action-parameter-binder: In the function that calls the GetParameterValue method to obtain the parameter, it obtains the corresponding IModelBinder according to the parameter description, that is, ParameterDescriptor, use the corresponding IModelBinder to obtain the parameter value. When no ModelBinder is specified for this parameter, MVC uses the default Model binding class DefaultModelBinder. so the first part of our extension is to specify the custom Model Binder for parameter binding. The custom Model Binder must inherit the IModelBinder. 2. inherit from IModelBinder and implement CustomeBinder 2.1. the Session dependency problem in MVC code is often seen in MVC code: copy the code public ActionResult Index () {var user = Session ["UserAccuont"] as UserAccount; // obtain the information of the current logon user from the Session // send email var email = user. email; return new EmptyResult ();} The above code needs to be Session. The value in the session results in the coupling of the Index method and Session, and there is no way to perform unit tests. In this case, we can define a CustomeBinder to solve this problem and remove the dependency of the Index method on the Session. 2.2 custom UserAccountModelBinder the UserAccountModelBinder we define inherits IModelBinder and implements the BindModel method. This method retrieves UserAccount information from the Session to construct the parameters required by the Action method. Public class UserAccountModelBinder: IModelBinder {public object BindModel (ControllerContext controllerContext, ModelBindingContext bindingContext) {if (controllerContext. HttpContext. Session ["UserAccuont"]! = Null) {return controllerContext. HttpContext. Session ["UserAccuont"];} return null;} 2.3 Register UserAccountModelBinder and register UserAccountModelBinder in Application_Start of the Global. asax. cs file. Protected void Application_Start () {// register UserAccountModelBinder. If you specify a parameter of the UserAccount type, it will be processed by UserAccountModelBinder. ModelBinders. Binders. Add (typeof (UserAccount), new UserAccountModelBinder ());..........} 2.4 modify the Index () method now because UserAccountModelBinder can process the UserAccount parameter retrieved from the Session, our Index method can be transformed to the following: public ActionResult Index (UserAccount user) {// var user = Session ["UserAccuont"] as UserAccount; // obtain the information of the current logon user from the Session // send email var email = user. email; return new EmptyResult ();} different from the original code, we do not need to use the Index method to obtain the user value from the session. It is automatically handled by UserAccountModelBinder. 2.5 let's take a look at the process behind it. The working method and process of the custome model binder. Request-> route resolution-> ControllerActionInvoker find ModelBinder processing parameters-> Find the bound custome model binder Based on the parameter type, that is, here UserAccountModelBinder-> UserAccountModelBinder assign values to the Action parameter from the Session. Iii. disadvantages of using Custom Model Binder the above UserAccountModelBinder does solve our Session dependency problem. However, this type of registration of binder may bring potential risks: all Action methods that use UserAccount as the parameter are processed by UserAccountModelBinder, that is, the values in the session. At this time, what will happen when submitting UserAccount on the Create and Edit pages of our UserAccount? Yes, it will be processed by UserAccountModelBinder, and the value of the submitted form cannot be obtained. Therefore, use the Custom Model Binder with caution. The most suitable example is to use the Custom Model Binder to bind the parameter. Its data source will only come from one place. In the above UserAccount application, the data source may come from two places, Session and form submission, so it is not suitable for Custom Model binder. A work und is to define another SessionUserAccount type. 4. Using Custom Model Binder can solve some of the binding problems, but the disadvantage is that type binding will lead to a wide range of applications and bring unexpected problems.