欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2022-07-05 22:37:54
在Asp.net MVC中, Model Binder是生命周期中的一个非常重要的部分。搞清楚Model Binder的流程,能够帮助理解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中看出来。

 

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能帮助我们解决一部分绑定问题,但是弊端是以类型绑定会导致应用的范围太广,带来意料不到的问题。