这篇博客真是干货，干得估计还有点“磕牙”，所以还提供视频和代码。但基础稍弱的同学，怕还是得自行补充一些基础知识——就一篇文章，确实没办法面面俱到。
- 视频和代码下载：Demo - 百度云盘 · 一起帮
- 参考原文：Automatic ModelState validation in ASP.NET MVC（英文强，基础好的同学可以直接看原文了）。
缘起
我忘了是不是在园子里讲过，我命名为“截断式编程”的写法。其主要目的，就是把简单的、过滤条件、“非主干的”逻辑放在最前面。比如在ASP.NET MVC的Action中，处理POST时，我们通常都要进行服务端验证，于是我们就可以这样写：
[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 = 伟大的程序员。
至少在目前，以及可预见的将来，对于开发人员而言，英语非常重要，非常重要，重要性怎么强调都不为过。大家可以试一下，有没有中文的类似的博客资料等，我没去试。但根据我的经验，相比于英文资料，中文资料是非常匮乏的。
关于使用搜索引擎，很多同学觉得这是一种“可耻的行为”，但其实不然。你一定要明白：你的目的是解决问题，而不是炫技，非得把什么东西都记在脑子里，非得什么都自己写出来……算了，这话可能很多人不接受，篇幅有限，懒得说了。懂的人一点就通，不懂的人你怎么说都没用。
最简单的情形
一开始解决方案还是比较简单的。我就直接放代码了：
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，哪怕返回的实际上是同一个页面。示例代码如下：
[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得到了错误提示信息
非常清晰，我图片和代码混用吧：
最核心代码：
/// <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(); 造成的空异常问题。