解读ASP.NET 5 & MVC6系列教程(12):基于Lamda表达式的强类型Routing实现

前面的深入理解Routing章节,我们讲到了在MVC中,除了使用默认的ASP.NET 5的路由注册方式,还可以使用基于Attribute的特性(Route和HttpXXX系列方法)来定义。本章,我们将讲述一种基于Lambda表达式的强类型类型。

这种方式的基本使用示例如下:

services.Configure<MvcOptions>(opt =>
{
 opt.EnableTypedRouting();

 opt.GetRoute("homepage", c => c.Action<ProductsController>(x => x.Index()));
 opt.GetRoute("aboutpage/{name}", c => c.Action<ProductsController>(x => x.About(Param<string>.Any)));
 opt.PostRoute("sendcontact", c => c.Action<ProductsController>(x => x.Contact()));
});

从示例中可以看出,我们可以通过GetRoute或PostRoute等扩展方法来定义route,而且后面使用Lambda表达式来定Controller的类型和Action的方法。

注意,在这里获取Action的方法名,是通过委托执行该Action方法来实现的(实际上并没有执行,而是基于此获取该Action的MethodInfo)。

实现原理

Stratup.csConfigureServices方法中配置services的时候,我们可以对MVC站点使用的核心配置文件MvcOptions进行配置,其中该类有一个ApplicationModelConventions属性(List<IApplicationModelConvention>)可以保存一个IApplicationModelConvention接口的集合,改接口可以对MVC程序的程序模型进行管线处理,该接口的定义如下:

public interface IApplicationModelConvention
{
 void Apply(ApplicationModel application);
}

接口中的Apply方法所接收的参数类型是ApplicationModel,而ApplicationModel有两个极其重要的内容可以供我们操作,一个是Controller模型集合,一个是各种Filter的集合,该类的定义如下:

public class ApplicationModel
{
 public ApplicationModel();

 public IList<ControllerModel> Controllers { get; }
 public IList<IFilter> Filters { get; }
}

这里最重要的就是ControllerModel类,该类的实例上保存了各种各样重要而又可以操作的信息,比如该类和相关Action上的路由定义数据,API描述信息,路由约束等等,这些信息都可以进行操作。

新的IApplicationModelConvention注册方式如下:

services.Configure<MvcOptions>(opt =>
{
 opts.ApplicationModelConventions.Add(new MyApplicationModelConvention());
});

所以我们可以利用这个方法,在合适的时机对整个MVC的程序模型做响应的调整和修改,本章节中的强类型路由就是利用这个特性来实现的。

实现步骤

首先定义一个强类型的路由模型TypedRouteModel类,该类要继承于AttributeRouteModelAttributeRouteModel类是基于Attribute路由的基本模型,TypedRouteModel类的代码如下:

public class TypedRouteModel : AttributeRouteModel
{
 public TypedRouteModel(string template)
 {
  Template = template;
  HttpMethods = new string[0];
 }

 public TypeInfo ControllerType { get; private set; }

 public MethodInfo ActionMember { get; private set; }

 public IEnumerable<string> HttpMethods { get; private set; }

 public TypedRouteModel Controller<TController>()
 {
  ControllerType = typeof(TController).GetTypeInfo();
  return this;
 }

 public TypedRouteModel Action<T, U>(Expression<Func<T, U>> expression)
 {
  ActionMember = GetMethodInfoInternal(expression);
  ControllerType = ActionMember.DeclaringType.GetTypeInfo();
  return this;
 }

 public TypedRouteModel Action<T>(Expression<Action<T>> expression)
 {
  ActionMember = GetMethodInfoInternal(expression);
  ControllerType = ActionMember.DeclaringType.GetTypeInfo();
  return this;
 }

 private static MethodInfo GetMethodInfoInternal(dynamic expression)
 {
  var method = expression.Body as MethodCallExpression;
  if (method != null)
   return method.Method;

  throw new ArgumentException("Expression is incorrect!");
 }

 public TypedRouteModel WithName(string name)
 {
  Name = name;
  return this;
 }

 public TypedRouteModel ForHttpMethods(params string[] methods)
 {
  HttpMethods = methods;
  return this;
 }
}

该类主要的功能是:定义支持传入Controller类型,支持链式调用。

然后再定义一个继承IApplicationModelConvention接口的TypedRoutingApplicationModelConvention类。代码如下:

public class TypedRoutingApplicationModelConvention : IApplicationModelConvention
{
 internal static readonly Dictionary<TypeInfo, List<TypedRouteModel>> Routes = new Dictionary<TypeInfo, List<TypedRouteModel>>();

 public void Apply(ApplicationModel application)
 {
  foreach (var controller in application.Controllers)
  {
   if (Routes.ContainsKey(controller.ControllerType))
   {
    var typedRoutes = Routes[controller.ControllerType];
    foreach (var route in typedRoutes)
    {
     var action = controller.Actions.FirstOrDefault(x => x.ActionMethod == route.ActionMember);
     if (action != null)
     {
      action.AttributeRouteModel = route;
      //注意这里是直接替换,会影响现有Controller上的Route特性定义的路由
      foreach (var method in route.HttpMethods)
      {
       action.HttpMethods.Add(method);
      }
     }
    }
   }
  }
 }
}

在该类中,保存了一个静态变量Routes,用于保存所有以Lamda表达式方式声明的路由,然后在现有的Controllers集合中进行查找及修改,然后替换AttributeRouteModel属性,并设置响应的Http Method(如果不设置,则默认所有的方式都允许)。

在这里,我们只是简单替换action.AttributeRouteModel,所以会导致一些缺陷(比如一个Action只能支持一个路由路径,以最后一个为准),各位同学可以根据自己的能力进行优化。

优化的时候,要注意Controller上的Route集合保存在controller.Attributes属性上,Action上的Route集合保存在action.Attributes属性上,可以对其进行优化。

然后,在MvcOptions上,我们再为TypeRouteModel添加一些扩展方法以方便使用,代码如下:

public static class MvcOptionsExtensions
{
 public static TypedRouteModel GetRoute(this MvcOptions opts, string template, Action<TypedRouteModel> configSetup)
 {
  return AddRoute(template, configSetup).ForHttpMethods("GET");
 }

 public static TypedRouteModel PostRoute(this MvcOptions opts, string template, Action<TypedRouteModel> configSetup)
 {
  return AddRoute(template, configSetup).ForHttpMethods("POST");
 }

 public static TypedRouteModel PutRoute(this MvcOptions opts, string template, Action<TypedRouteModel> configSetup)
 {
  return AddRoute(template, configSetup).ForHttpMethods("PUT");
 }

 public static TypedRouteModel DeleteRoute(this MvcOptions opts, string template, Action<TypedRouteModel> configSetup)
 {
  return AddRoute(template, configSetup).ForHttpMethods("DELETE");
 }

 public static TypedRouteModel TypedRoute(this MvcOptions opts, string template, Action<TypedRouteModel> configSetup)
 {
  return AddRoute(template, configSetup);
 }

 private static TypedRouteModel AddRoute(string template, Action<TypedRouteModel> configSetup)
 {
  var route = new TypedRouteModel(template);
  configSetup(route);

  if (TypedRoutingApplicationModelConvention.Routes.ContainsKey(route.ControllerType))
  {
   var controllerActions = TypedRoutingApplicationModelConvention.Routes[route.ControllerType];
   controllerActions.Add(route);
  }
  else
  {
   var controllerActions = new List<TypedRouteModel> { route };
   TypedRoutingApplicationModelConvention.Routes.Add(route.ControllerType, controllerActions);
  }

  return route;
 }

 public static void EnableTypedRouting(this MvcOptions opts)
 {
  opts.ApplicationModelConventions.Add(new TypedRoutingApplicationModelConvention());
 }
}

在上述代码中,我们添加了一个EnableTypedRouting扩展方法,以便向MvcOptions.ApplicationModelConventions属性上添加新的TypedRoutingApplicationModelConvention类型示例。

其它的扩展方法则都是用于声明相关的route,大家注意,在最开头的示例中,我们看到获取action信息的方法是通过委托调用该action方法(但没有真正调用),但是有的方法有参数,那怎么办呢?为此,我们定于一个忽略参数的Param类,代码如下:

public static class Param<TValue>
{
 public static TValue Any
 {
  get { return default(TValue); }
 }
}

这样,我们为含有参数的About方法定于路由的时候,就可以这样来定义了,代码如下:

opt.GetRoute("aboutpage/{name}", c => c.Action<HomeController>(x => x.About(Param<string>.Any)));

另外,由于TypeRouteModel里很多方法都是可以链式调用,所以我们也可以通过这种方式为route指定一个名称,示例代码如下:

opt.GetRoute("homepage", c => c.Action<HomeController>(x => x.Index())).WithName("foo");

至此,整个强类型路由的功能就实现完毕了,大家在使用的时候,就多了一种选择了。

弊端(或Bug)

我们看到,在上面实现IApplicationModelConvention接口的时候,我们只是简单的对action.AttributeRouteModel进行替换,也就是说,如果你在Action上已经了Route特性的话,他会把你的信息给你覆盖掉,从而导致你的route失效。比如,如果你定义了一个这样的自定义路由:

public class ProductsController : Controller
{
 [Route("index")]
 public IActionResult Index()
 {
  return Content("Index");
 }
}

然后又通过Lamda表达式又定义了强类型路由,代码如下:

opt.GetRoute("homepage", c => c.Action<ProductsController>(x => x.Index()));

那么,你只能通过/homepage开来访问,而不能通过/index来访问了,因为它把你的Route给你覆盖掉了。

但是,上述Lamda表达式方式并没有覆盖Controller上定义的Route特性定义,所以如果你在ProductsController上定义了Route特性的话,两者就会组合在一起,例如:

[Route("products")]
public class ProductsController : Controller
{
 public IActionResult Index()
 {
  return Content("Index");
 }
}

那么你的访问网址应该是/products/homepage,而不是/homepage。不过如果你在Lamda表达式方式里的代码,是如下这样的话:

opt.GetRoute("/homepage", c => c.Action<ProductsController>(x => x.Index()));

那你的访问网址就应该是/homepage了,因为该路由字符是绝对路径/homepage,而不是homepage

参考:http://www.strathweb.com/2015/03/strongly-typed-routing-asp-net-mvc-6-iapplicationmodelconvention/

(0)

相关推荐

  • ASP.NET中URL Routing和IIS上URL Rewriting的区别

    前言 前面有2篇帖子提到了关于URL Routing的特性,但是发现有很多人误会URL Routing就是URl Rewriting,其实2个虽然都提供相似的功能(提高友好的URL方便搜索引起收录),但是2者的原理和运行周期是完全不一样的,本篇文章我们就来分析一下具体有什么不同. 例子 在分析原理之前,我们先来做一个例子测试一下(IIS URL Rewrite模块需要IIS7的支持). 1.为Customer/1的URL建立对应的MVC程序 首先建立一个普通的MVC3程序,建立一个简单的Cust

  • 在IIS7中应用Application Request Routing配置反向代理的图文教程

    在配置web服务器的时候,我们经常遇到这样的问题,由于某些原因,该服务器只能拥有一个公网IP,但是可能需要提供其他机器或者本机上其他webserver的服务器给访问者,同时又不希望使用其他端口,如果在linux下,常见的解决方案是使用nginx作为前端server,通过反向代理间接访问其他webserver.在IIS7之前,在windows上要实现该功能却不是一件容易的事情,但是在IIS7上,通过Application Request Routing模块,我们可以轻松实现反向代理. 本次测试配置

  • 在ASP.NET中用MSDNURLRewriting实现Url Rewriting

    作者:Scott Mitchell翻译:Janssen1.0.请一定要抱着批评的态度来看该文章 1.1. 概要分析如何使用微软提供的ASP.NET来对动态产生的URL地址进行网址重写.网址重写是实现一种截取网址请求并将其进行处理后重新指向到一个指定的网址的过程.作者本人在对各种实现网址重写的技术进行研究和探讨后得出的经验和方法,希望能对您有所帮助. 1.2. 内容简介稍微花点时间看一看你做的网站里头的URL地址,你看到类似这样的地址吗http://yoursite.com/info/dispEm

  • ASP.NET MVC3 SEO优化:利用Routing特性提高站点权重

    简介 我们在开发互联网程序的时候,有个很重要的事情就是做搜索引擎优化(SEO),我们都知道ASP.NET MVC程序提供了友好的URL以及永久重定向的支持,这些友好的URL是利用Routing系统的特性来支持的,但是在这个Routing里有个问题,就是多个不同的地址和指向同一个action方法,那对于搜索引擎来说就意味着你的站点有很多地址的内容都是重复的. 本章内容将展示如果解决这一问题. 正文 对于SEO,一个地址对应一个唯一独立的内容是保证最好权重的一个重要步骤,所以我们需要确保每一个URL

  • 解读ASP.NET 5 & MVC6系列教程(11):Routing路由

    新版Routing功能介绍 在ASP.NET 5和MVC6中,Routing功能被全部重写了,虽然用法有些类似,但和之前的Routing原理完全不太一样了,该Routing框架不仅可以支持MVC和Web API,还支持一般的ASP.NET5程序.新版的改变有如下几个部分. 首先,Routing系统是基于ASP.NET 5的,是一个独立于MVC的路由框架,而不是基于MVC的.MVC只是在上面扩展了一个快捷方式而已. 其次,在ASP.NET 5中,MVC和Web API控制器没有区别了,即合二为一了

  • 解读ASP.NET 5 & MVC6系列教程(12):基于Lamda表达式的强类型Routing实现

    前面的深入理解Routing章节,我们讲到了在MVC中,除了使用默认的ASP.NET 5的路由注册方式,还可以使用基于Attribute的特性(Route和HttpXXX系列方法)来定义.本章,我们将讲述一种基于Lambda表达式的强类型类型. 这种方式的基本使用示例如下: services.Configure<MvcOptions>(opt => { opt.EnableTypedRouting(); opt.GetRoute("homepage", c =>

  • 解读ASP.NET 5 & MVC6系列教程(1):ASP.NET 5简介

    ASP.NET 5简介 ASP.NET 5是一个跨时代的改写,所有的功能和模块都进行了独立拆分,做到了彻底解耦.为了这些改写,微软也是蛮 拼的,几乎把.NET Framwrok全部改写了一遍,形成了一个.NET Core的东西. 在.NET Core里一切都是可配置的,包括Session.MVC等功能,而一切可配置的功能都是可以在Nuget上进行下载. 目前ASP.NET 5依旧兼容老的.NET Framwrok,但要在进行跨平台的部署,还是只能使用新改版的.NET Core CLR. 目前的A

  • 解读ASP.NET 5 & MVC6系列教程(13):TagHelper

    在新版的MVC6中,微软提供了强大的TagHelper功能,以便让我们摆脱如下的臃肿代码: @Html.LabelFor(model => model.FullName) @Html.EditFor(model => model.FullName) @Html.ValidationMessageFor(model => model.FullName) 引入新功能TagHelper以后,我们只需要这样定义就可以了,代码如下: @addTagHelper "*, Microsoft

  • 解读ASP.NET 5 & MVC6系列教程(7):依赖注入

    在前面的章节(Middleware章节)中,我们提到了依赖注入功能(Dependency Injection),ASP.NET 5正式将依赖注入进行了全功能的实现,以便开发人员能够开发更具弹性的组件程序,MVC6也利用了依赖注入的功能重新对Controller和View的服务注入功能进行了重新设计:未来的依赖注入功能还可能提供更多的API,所有如果还没有开始接触依赖注入的话,就得好好学一下了. 在之前版本的依赖注入功能里,依赖注入的入口有MVC中的IControllerFactory和Web A

  • 解读ASP.NET 5 & MVC6系列教程(2):初识项目

    初识项目 打开VS2015,创建Web项目,选择ASP.NET Web Application,在弹出的窗口里选择ASP.NET 5 Website模板创建项目,图示如下: 我们可以看到,此时Web Forms\MVC\Web API复选框都选择不了,原有是因为在ASP.NET 5中做了大量更改,移除了Web Forms功能,将MVC.Web API.Web Pages这些功能合在了一起,所以自然就不需要这些复选框了.另外由于是CTP版,所以目前还没有提供单元测试项目的创建. 新创建的项目在VS

  • 解读ASP.NET 5 & MVC6系列教程(17):MVC中的其他新特性

    (GlobalImport全局导入功能) 默认新建立的MVC程序中,在Views目录下,新增加了一个_GlobalImport.cshtml文件和_ViewStart.cshtml平级,该文件的功能类似于之前Views目录下的web.config文件,之前我们在该文件中经常设置全局导入的命名空间,以避免在每个view文件中重复使用@using xx.xx语句. 默认的示例如下: @using BookStore @using Microsoft.Framework.OptionsModel @a

  • 解读ASP.NET 5 & MVC6系列教程(16):自定义View视图文件查找逻辑

    之前MVC5和之前的版本中,我们要想对View文件的路径进行控制的话,则必须要对IViewEngine接口的FindPartialView或FindView方法进行重写,所有的视图引擎都继承于该IViewEngine接口,比如默认的RazorViewEngine.但新版本MVC6中,对视图文件的路径方式却不太一样了,目前有两种方式,一种是通过RazorViewEngine,另外一种是通过新特性IViewLocationExpander接口. 通过RazorViewEngine来控制View路径

  • 解读ASP.NET 5 & MVC6系列教程(15):MvcOptions配置

    程序模型处理 IApplicationModelConvention 在MvcOptions的实例对象上,有一个ApplicationModelConventions属性(类型是:List<IApplicationModelConvention>),该属性IApplicationModelConvention类型的接口集合,用于处理应用模型ApplicationModel,该集合是在MVC程序启动的时候进行调用,所以在调用之前,我们可以对其进行修改或更新,比如,我们可以针对所有的Control

  • 解读ASP.NET 5 & MVC6系列教程(14):View Component

    在之前的MVC中,我们经常需要类似一种小部件的功能,通常我们都是使用Partial View来实现,因为MVC中没有类似Web Forms中的WebControl的功能.但在MVC6中,这一功能得到了极大的改善.新版MVC6中,提供了一种叫做View Component的功能. 你可以将View Component看做是一个mini的Controller--它只负责渲染一小部分内容,而非全部响应,所有Partial View能解决的问题,你都可以使用View Component来解决,比如:动态

随机推荐