Asp.net MVC的Model Binder工作流程以及扩展方法(1) - Custom Model Binder

在Asp.net MVC中, Model Binder是生命周期中的一个非常重要的部分。搞清楚Model Binder的流程，能够帮助理解Model Binder的背后发生了什么。同时该系列文章会列举MVC中Model Binder的扩展点，以及如何使用这些扩展点。

阅读目录:

一. MVC中的Model Binder的工作流程

二. 继承IModelBinder, 实现CustomeBinder

三. 使用Custom Model Binder的弊端

四. 总结

一, MVC中的Model Binder的工作流程

在MVC中, 当一个请求发送到服务器，先是要经过Route匹配, 找到对应的Controller和Action， 然后才是构建Action中的参数，也就是Model Binder的过程
这个可以从MVC的源码, ControllerActionInvoker中看出来。

在调用方法GetParameterValue获取参数的函数中, 会根据参数的描述信息，也就是ParameterDescriptor来获取对应的IModelBinder, 使用对应的IModelBinder来获取参数的值。在没有特殊为该参数指定ModelBinder的情况下, MVC使用默认的Model绑定类DefaultModelBinder.

所以我们扩展的第一处地方是，为参数绑定指定使用我们自定义的Model Binder, 自定义的Model Binder需要继承IModelBinder.

二, 继承IModelBinder, 实现CustomeBinder

2.1. MVC代码中的Session依赖问题

MVC的代码中，常常能够看到这样的代码:

public ActionResult Index() 
{ 
          var user = Session["UserAccuont"] as UserAccount; //从Session中获取当前登录用户的信息 
          //send email 
          var email = user.Email; 
          return new EmptyResult(); 
}

上面代码，需要从session中取得当前登录用户的信息。从session中取值导致了Index方法和Session耦合，也没办法进行单元测试。这个时候我们可以定义一个CustomeBinder来解决这个问题，解除Index方法对于Session的依赖。

2.2 自定义UserAccountModelBinder

我们定义的UserAccountModelBinder继承IModelBinder，实现了BindModel方法。该方法会从Session中取得UserAccount信息来构建Action方法中所需要的参数。

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 注册UserAccountModelBinder

在Global.asax.cs文件的Application_Start中, 注册UserAccountModelBinder。

protected void Application_Start() 
{ 
           //注册UserAccountModelBinder, 指定UserAccount类型的参数，将会由UserAccountModelBinder来处理。

           ModelBinders.Binders.Add(typeof(UserAccount), new UserAccountModelBinder());

……….

}

2.4 修改Index()方法

现在由于UserAccountModelBinder能够处理从Session中取UserAccount参数，所以我们的Index方法可以改造成这样:

public ActionResult Index(UserAccount user) 
{ 
          //var user = Session["UserAccuont"] as UserAccount; //从Session中获取当前登录用户的信息 
          //send email 
          var email = user.Email; 
          return new EmptyResult(); 
}

和最初代码不同之处是，我们的从session中取得user值的代码，不需要在Index方法中。而是由UserAccountModelBinder自动处理了。

2.5 背后的流程

现在来理一理，custome model binder的工作方法和流程。

request –> route解析 –> ControllerActionInvoker找ModelBinder处理参数 –> 根据参数类型寻找绑定的custome model binder, 也就是这里的UserAccountModelBinder –> UserAccountModelBinder 从Session中为Action的参数赋值。

三, 使用Custom Model Binder的弊端

上面的UserAccountModelBinder 的确解决了我们的Session依赖问题，但是这种以类型注册binder的方式，会带来潜在的风险:

由于所有使用UserAccount为参数的Action方法，都会由UserAccountModelBinder来处理，也就是从session中取值。如果这个时候，我们的UserAccount的Create和Edit页面，提交UserAccount会发生什么? 是的，都会被UserAccountModelBinder处理，无法得到提交表单的值。

所以要慎用Custom Model Binder, 比较适合的例子是使用Custom Model Binder来绑定的参数，它的数据源只会来源于一处。上面的UserAccount在应用中，数据源就可能来自两处，Session和表单提交，所以是不适合Custom Model binder. 一个变通的办法是，再定义个类型SessionUserAccount.

四, 总结

使用Custom Model Binder能帮助我们解决一部分绑定问题，但是弊端是以类型绑定会导致应用的范围太广，带来意料不到的问题。

下一篇中，我们将使用CustomModelBinderAttribute来解决同样的问题，如果Custom Model Binder是全火力覆盖，那么CustomModelBinderAttribute就是定点清除。