浅论ASP.NET MVC参数映射的优缺点

          ASP.NET MVC中，参数映射或路由映射是一个非常简便的特性，可以直接将URL查询参数映射为控制器方法的参数。但是在实际使用中，还是要需要斟酌使用。

         1、优点

         简便，不需要从HttpContext上下文对象中来读取键值对。现在我们用控制起来实现一个两个整数相加，其代码大致如下：

     public string Add(int firstNum, int secondNum)        {            return (firstNum + secondNum).ToString();        }

         当参数比较少，而且后期变动较少的时候，适合采用这种形式。

        2、缺点

        由于MVC往往和EF等ORM框架结合使用，在真实场景下，我们往往需要向后台发送在JS中编码好的实体JSON数据。在控制器中接受后再反序列化为实体。在这种情况下，存在某种程度的限制。主要体现在两个方面：

      （1）如果直接使用实体模型来进行反序列化，意味着在JSON必须满足实体的验证要求。主要体现在某些字段不可空，从而使JS与数据库实体产生了紧密的耦合。比如插入一条计划，其插入时间是在服务器端生成的，但是在JS中必须为这个字段指定值，否则无法在控制器中反序列化。特别在一些复杂场景下，发送部分实体数据是很常见的情况。有人提出了参数模型的概念，就是想在实体模型层之上再构建一个模型层，用于处理类似的交叉、片段的需求。

      （2）控制器参数与js紧耦合。控制器方法基本都是供JS调用的。在前端需求发生变化的时候，我们不得不频繁的更改控制器的参数。因而网上很多人问控制器为什么不能重载。参数命名也是个很头疼的问题。这些因素导致控制器方法并未像我们的本意一样，成为一个真正稳定的”框架方法“，需要根据前台的需求不断的变化。特别是在参数较多的时候，非常难看。

       最近看到一段登录代码挺有意思：

  public ActionResult UserLogin()        {            NameValueCollection collection = HttpContext.Request.HttpMethod == "POST" ? HttpContext.Request.Form : HttpContext.Request.QueryString;            string userName = string.IsNullOrEmpty(collection["u"]) ? "" : EncryptHelper.Base64Decode(collection["u"]);            string passWord = string.IsNullOrEmpty(collection["p"]) ? "" : EncryptHelper.Base64Decode(collection["p"]);            //****        }

       注意这里的控制器中并没有参数，参数是从上下文中读取的。由于登录方法是一个简单的，参数恒定的方法，直接使用参数映射也是可以的。重要的是UserLogin()真正的成为了一个独立接口：理论上说，我们只需要一个这样的方法即可完成所有的请求O(∩_∩)O~。在这种思路下，可以序列化的数据序列化为JSON后传过来，无需序列化的单独参数单独传送。从而避免了在控制器中为参数命名绞尽脑汁。