Asp.net MVC的Model Binder工作流程以及扩展方法(1)
阅读目录:
一. MVC中的Model Binder的工作流程
二. 继承IModelBinder, 实现CustomeBinder
三. 使用Custom Model Binder的弊端
四. 总结
一, MVC中的Model Binder的工作流程
在MVC中, 当一个请求发送到服务器，先是要经过Route匹配, 找到对应的Controller和Action， 然后才是构建Action中的参数，也就是Model Binder的过程
这个可以从MVC的源码, ControllerActionInvoker中看出来。
blog-action-parameter-binder
在调用方法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能帮助我们解决一部分绑定问题，但是弊端是以类型绑定会导致应用的范围太广，带来意料不到的问题。