Asp.net MVC的Model Binder工作流程以及扩展方法(1)
在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就是定点清除。
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。