这篇博客真是干货,干得估计还有点“磕牙”,所以还提供视频和代码。但基础稍弱的同学,怕还是得自行补充一些基础知识——就一篇文章,确实没办法面面俱到。
- 视频和代码下载:Demo - 百度云盘 · 一起帮
- 参考原文:Automatic ModelState validation in ASP.NET MVC(英文强,基础好的同学可以直接看原文了)。
缘起
我忘了是不是在园子里讲过,我命名为“截断式编程”的写法。其主要目的,就是把简单的、过滤条件、“非主干的”逻辑放在最前面。比如在ASP.NET MVC的Action中,处理POST时,我们通常都要进行服务端验证,于是我们就可以这样写:
![](https://yqfile.alicdn.com/img_1c53668bcee393edac0d7b3b3daff1ae.gif?x-oss-process=image/resize,w_1400/format,webp)
![](https://yqfile.alicdn.com/img_405b18b4b6584ae338e0f6ecaf736533.gif?x-oss-process=image/resize,w_1400/format,webp)
[HttpPost] public ActionResult Send(MessageSendModel model) { #region 非截断式写法 //if (ModelState.IsValid) //{ // //假设发送了一个消息 // Response.Write("消息已经发送"); //} //return View(model); #endregion #region 截断式编程 //过滤条件 if (!ModelState.IsValid) { return View(model); } //主干程序:假设发送了一个消息 Response.Write("消息已经发送"); return RedirectToAction("Send"); #endregion }
由于采用了这种写法,我们很快就发现了一个问题:if (!ModelState.IsValid) { return View(model); }到处都是。
是不是有点“坏味道”的感觉?你是不是想怎么“弄”它一下?
ActionFilter
首先想到的,当然就是ActionFilter了:在Action执行之前,用一个Filter进行检查,不就OK了吗?
我觉得这个想法不错,但是,但是,请注意,一定要问一个为什么!为什么别人想不到呢?——这怎么可能?!
所以,在自己动手之前,养成习惯,google/bing一下,看看别人是怎么弄的。
果不其然,找到一篇博客::Automatic ModelState validation in ASP.NET MVC ,和我的思路一模一样!\(^o^)/
而且,他想得比我更周全!看得我那个兴奋啊……
所以,这里我们得到的第一个经验:动手之前先搜一搜,不要重复造轮子。
再引申开一点,
英文 + google = 伟大的程序员。
至少在目前,以及可预见的将来,对于开发人员而言,英语非常重要,非常重要,重要性怎么强调都不为过。大家可以试一下,有没有中文的类似的博客资料等,我没去试。但根据我的经验,相比于英文资料,中文资料是非常匮乏的。
关于使用搜索引擎,很多同学觉得这是一种“可耻的行为”,但其实不然。你一定要明白:你的目的是解决问题,而不是炫技,非得把什么东西都记在脑子里,非得什么都自己写出来……算了,这话可能很多人不接受,篇幅有限,懒得说了。懂的人一点就通,不懂的人你怎么说都没用。
最简单的情形
一开始解决方案还是比较简单的。我就直接放代码了:
![](https://yqfile.alicdn.com/img_1c53668bcee393edac0d7b3b3daff1ae.gif?x-oss-process=image/resize,w_1400/format,webp)
![](https://yqfile.alicdn.com/img_405b18b4b6584ae338e0f6ecaf736533.gif?x-oss-process=image/resize,w_1400/format,webp)
public class ValidateModelStateAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { if (!viewData.ModelState.IsValid) { filterContext.Result = new ViewResult(); } } }
理解的难点大概就在于为什么:return View(); 和 filterContext.Result = new ViewResult(); 是等价的。
我觉得有这个问题的根源还是没有理解“面向对象”,这一直是.NET阵营程序员所缺乏的。
一起帮的QQ群里有时候就有同学犯迷糊,聊了之后,我就明白了,他始终把return View();认为是“转到那个View页面”的意思,而没有能够理解成:这就是一个方法,返回的是一个ActionResult对象。大家能明白我的意思吧?所有的Action都是一个方法,一个返回ActionResult对象的方法,然后ASP.NET MVC框架根据这个ActionResult对象,找到相应的View进行呈现(Render)。这中间多了一个环节,但这不是“脱了裤子放屁”,是非常有必要的,而且非常“精妙”的一个架构设计。
你看,这样Filter里就可以通过给filterContext.Result赋值而达到页面呈现的效果。当然,这么做最大的好处还在于UI层的“可测试化”,这又是一个非常庞杂的话题,此处先略过。
多说一句,一定要说这一句:感谢这位同学提出问题,让我知道作为初学者,那些地方是难点。话说,我做直播这么久,要收到点反馈可真难啊!
然而,这里有一个问题
如果没有bing(话说不能google真特么的悲剧)一下,我肯定就到此为止了。然而,高手就是高手,Ben Foster想到了另外一个问题:
假设页面中需要由后台传来的数据才能正常呈现时,如何在Filter里赋值,再传递给View?
这样说有点晕,所以我才专门弄了一个Demo,用DropdownList做例子。DropdownList的可选项数据是从后台获取的,由于HTTP的“无状态协议”特征,POST不能“继承”GET时获取的数据,咋办呢?
TempData解围
很多种办法,Ben Foster的博客里是封装一个方法,GET和POST都调用。
我以前项目,是利用的MVC中的TempData,在两个请求见共享数据。这样,如果可选项数据是从数据库获取的,可以减少一次查询,有一点点性能上的提高。
TempData真是一个非常好的东西,这就是我喜欢.NET的原因,它非常的“贴心”,给人的感觉是“始终面向一线开发人员”的,它知道你在写代码的时候可能会遇到什么问题,从而事先给你准备好解决方案。
思路和实现都很简单:GET的时候,就把POST需要的数据存到TempData中;POST的时候,就把TempData中的数据取出来(需要一个强制转换,因为数据是存放为Object类型的)。
代码就不贴了,因为这不是最终的解决方案。
但FilterAction里肿么办
在Controller里面你怎么玩都行,但我们现在要“封装”啊,我们要在Filter里解决这个问题啊!
傻眼了。关键的问题在于我们需要在OnActionExecuting(Action执行之前)进行验证,而此时Action的ViewModel并没有生成,我们可以从ControllerBase.ActionParameters 中取值,但取出来的是一个Object类型,你不知道要把它转换成什么类型的(当然你可以用反射做,但非常复杂,复杂到你都觉得没有必要),TempData也是一样的问题。
每次这个时候,我就会想起ASP.NET WebForm中的ViewState来,那些年认为它是“性能杀手”,对它口诛笔伐。MVC的诞生并流行,估计和这玩意就有非常大(多大呢?我乱说的,三成吧)的关系。
但现在MVC没ViewState了,要自己处理,呵呵,又有点怀恋以前WebForm开发的“便捷”了。
再展开来说,DateSet,Linq to SQL,Entity Framework……一系列的技术,一经推出,都是吵吵嚷嚷,不可开交。其实何必呢,各有各的用处,各有各的适用场景,脱离了具体的业务要求,能争出个什么高下来?
所以我一直强调,软件工程,技术选择以解决问题为标准。问题千差万别,所以使用的技术不可能整齐划一,一句话,“没有银弹”。
PRG模式
如果是我的话,这时候就放弃了。但Ben Foster给出了一个非常棒的解决方案:利用PRG模式。
PRG是Post, Redirect, Get的缩写,意思是所有的POST请求,都Redirect到GET的Action,哪怕返回的实际上是同一个页面。示例代码如下:
![](https://yqfile.alicdn.com/img_1c53668bcee393edac0d7b3b3daff1ae.gif?x-oss-process=image/resize,w_1400/format,webp)
![](https://yqfile.alicdn.com/img_405b18b4b6584ae338e0f6ecaf736533.gif?x-oss-process=image/resize,w_1400/format,webp)
[HttpPost] public ActionResult Send(MessageSendModel model) { //主干程序:假设发送了一个消息 Response.Write("消息已经发送"); //注意:不是return View() //1、是Redirect //2、重定向的这个Action是和自己同名的,都是Send return RedirectToAction("Send"); }
我非常欣慰的是我们的系统架构,一开始就是按照这个原则搭建的。最早接触PRG模式的时候,我也是有点迷迷糊糊的,但想到大家都这样用,而且看起来也没什么坏处,就采用了,后来真的是,一次又一次的发现这种模式的便利。这次又是这样搭上了“便车”。
记得我在直播里说过的:如果架构中出现了很多稀奇古怪难以克服的问题,一般来说,就是因为你没走在大道上。
通用的惯例模式,就是大道,别人已经走过的路啊。你循着别人走过的道走,碰到问题的时候,也一样会比较容易的找到解决问题的方案;你要独辟蹊径——通常情况下可能不是你想独辟蹊径,呵呵,多半是自己走岔了吧——那荒山野岭的,确实很难找到求助。
终极方案
思路就是:
- 在Action的POST的Filter里,如果未通过验证,就把ModelState存放在TempData之中;
- 给Aciton的GET也添加一个Filter,用于取出TempData中的ModelState,并Merge到自己的ModelState中。
- 于是,通过Redirect,GET的Action得到了错误提示信息
非常清晰,我图片和代码混用吧:
最核心代码:
![](https://yqfile.alicdn.com/img_1c53668bcee393edac0d7b3b3daff1ae.gif?x-oss-process=image/resize,w_1400/format,webp)
![](https://yqfile.alicdn.com/img_405b18b4b6584ae338e0f6ecaf736533.gif?x-oss-process=image/resize,w_1400/format,webp)
/// <summary> /// Exports the current ModelState to TempData (available on the next request). /// </summary> protected static void ExportModelStateToTempData(ControllerContext context) { context.Controller.TempData[Key] = context.Controller.ViewData.ModelState; } /// <summary> /// Populates the current ModelState with the values in TempData /// </summary> protected static void ImportModelStateFromTempData(ControllerContext context) { var prevModelState = context.Controller.TempData[Key] as ModelStateDictionary; context.Controller.ViewData.ModelState.Merge(prevModelState); }
就这么简单,完美!回味无穷。
其实,在POST的Action里return View();并不是一个好套路。
在我的项目我就发现了这么一个问题:当return的View()里还含有@Html.Action()调用,且该调用需要区分GET和POST时,会进入POST所属的ChildAction,这肯定是不符合逻辑的。(表述起来好吃力!慢慢看,一边看一边想,想不明白的看视频吧……)
题外话
磨蹭了一天,终于写完了。
写得好累,感觉写这一篇文章比那90分钟的视频还累,难怪现在好多开源项目都没文档,直接上视频了……
最后说说“一起帮”吧,现在已经被当初的乞丐版强多了,隔三差五的也有同学在上面提问,算是有些生气了,但人气还是远远的不够,根据QQ群里投票结果,现在主要精力应放在做推广上。
推广了好几天了,有点效果,但唉呀我的妈呀!这推广,比写这篇博客还累,咋整?
园子里就不说这些了。“酒向知己饮,诗向会人吟”,以后博客园只会讲技术,这也是博客园欢迎的。想聊点编程以外的,欢迎加QQ群:
179742319(付费入群抢红包),312423951(验证入群)
以及关注微信公众号:我们一起帮。
感谢评论区
@敲代码的吃货:
如果采用PRG的方案,就不能达到你的要求:“把提交上来的数据再次呈现以便修改的”。要满足这种需求,只能在POST里return View(model); model里是带着之前数据的。
@stoneniqiu:
该方案的优势不是“减少”代码量,而是从架构层面,解决POST中return View(); 造成的空异常问题。