剖析ASP.NET Core（Part 3）- UseMvc（译）

原文：https://www.stevejgordon.co.uk/asp-net-core-anatomy-part-3-addmvc
发布于：2017年4月
环境：ASP.NET Core 1.1

本系列前面两篇文章介绍了ASP.NET Core中IServiceCollection两个主要扩展方法（AddMvcCore与AddMvc）。当你准备在程序中使用MVC中间件时，它们用来添加所需的MVC服务。

接下来，要在ASP.NET Core程序中启动MVC还需要在Startup类的Configure方法中执行UseMvc IApplicationBuilder扩展方法。该方法注册MVC中间件到应用程序管道中，以便MVC框架能够处理请求并返回响应（通常是view result或json）。本文我将分析一下在应用程序启动时UserMvc方法做了什么。

和先前文章一样，我使用rel/1.1.2 MVC版本库作为分析对象。代码是基于原来的project.json，因为在VS2017中似乎没有简单办法实现调试多个ASP.NET Core源代码。

UseMvc是IApplicationBuilder的一个扩展方法，带有一个Action<IRouteBuilder>委托参数。IRouteBuilder将被用于配置MVC的路由。UserMvc还有一个重载方法，不需要任何参数，它只是简单的传递一个空委托调用主函数。如下：

public static IApplicationBuilder UseMvc(this IApplicationBuilder app)
{
    if (app == null)
    {
        throw new ArgumentNullException(nameof(app));
    }

    return app.UseMvc(routes =>
    {
    });
}

主UseMvc方法：

public static IApplicationBuilder UseMvc(
    this IApplicationBuilder app,
    Action<IRouteBuilder> configureRoutes)
{
    if (app == null)
    {
        throw new ArgumentNullException(nameof(app));
    }

    if (configureRoutes == null)
    {
        throw new ArgumentNullException(nameof(configureRoutes));
    }

    // Verify if AddMvc was done before calling UseMvc
    // We use the MvcMarkerService to make sure if all the services were added.
    if (app.ApplicationServices.GetService(typeof(MvcMarkerService)) == null)
    {
        throw new InvalidOperationException(Resources.FormatUnableToFindServices(
            nameof(IServiceCollection),
            "AddMvc",
            "ConfigureServices(...)"));
    }

    var middlewarePipelineBuilder = app.ApplicationServices.GetRequiredService<MiddlewareFilterBuilder>();
    middlewarePipelineBuilder.ApplicationBuilder = app.New();

    var routes = new RouteBuilder(app)
    {
        DefaultHandler = app.ApplicationServices.GetRequiredService<MvcRouteHandler>(),
    };

    configureRoutes(routes);

    routes.Routes.Insert(, AttributeRouting.CreateAttributeMegaRoute(app.ApplicationServices));

    return app.UseRouter(routes.Build());
}

我们来分析一下此方法。首先检查IServiceProvider中是否有MvcMarkerService服务注册。为此使用ApplicationServices属性暴露IServiceProvider，再调用GetService，尝试查找已注册的MvcMarkerService。MvcMarkerService在AddMvcCore执行时已被注册，因此如果没有找到，则表明在ConfigureServices执行前没有调用过AddMvc或AddMvcCore。这样的Marker Services在很多地方使用，它可以帮助在代码执行之前，检查是否存已存在正确的依赖关系。

接下来，UserMvc从ServiceProvider请求一个MiddlewareFilterBuilder，并使用IApplicationBuilder.New()方法设定其ApplicationBuilder。当调用此方法时，ApplicationBuilder会创建并返回自身的新实例副本。

再下来，UserMvc初始化一个新的RouteBuilder，同时设定默认处理程序（default handler）为已注册的MvcRouteHandler。此时DI就像有魔力，一堆依赖对象开始实例化。这里请求MvcRouteHandler是因为其构造函数中有一些依赖关系，所以相关的其它类也会被初始化。每个这些类的构造函数都会请求额外的依赖关系，然后创建它们。这是DI系统工作的一个完美例子。虽然在ConfigureServices中所有的接口和具体实现已在container中注册，但实际对象只会在被注入时创建。通过创建RouteBuilder，对象创建就像滚雪球，直到所有依赖关系都被构造。一些对象作为单例模式注册，无论ServiceProvider是否请求都会创建，其生命周期贯穿整个应用程序。其它对象可能是在每次请求时通过构造函数创建或者其它情况，每次创建的对象都是特有的。了解依赖注入是如何工作的，特别是ASP.NET Core ServiceProvider的详细信息超出了这篇文章的范围。

RouteBuilder创建之后，Action<IRouteBuilder>委托被调用，使用RouteBuilder作为唯一参数。在MvcSandbox示列中，我们称之为UseMvc方法，通过一个lambda传递给代理方法。此功能将映射一个名为“default”的路由，如下所示：

app.UseMvc(routes =>
{
    routes.MapRoute(
        name: "default",
        template: "{controller=Home}/{action=Index}/{id?}");
});

MapRoute是IrouteBuilder的一个扩展方法，主要的MapRoute方法如下所示：

public static IRouteBuilder MapRoute(
    this IRouteBuilder routeBuilder,
    string name,
    string template,
    object defaults,
    object constraints,
    object dataTokens)
{
    if (routeBuilder.DefaultHandler == null)
    {
        throw new RouteCreationException(Resources.FormatDefaultHandler_MustBeSet(nameof(IRouteBuilder)));
    }

    var inlineConstraintResolver = routeBuilder
        .ServiceProvider
        .GetRequiredService<IInlineConstraintResolver>();

    routeBuilder.Routes.Add(new Route(
        routeBuilder.DefaultHandler,
        name,
        template,
        new RouteValueDictionary(defaults),
        new RouteValueDictionary(constraints),
        new RouteValueDictionary(dataTokens),
        inlineConstraintResolver));

    return routeBuilder;
}

这将请求一个由ServiceProvider解析的IinlineConstraintResolver实例给DefaultInlineConstraintResolver。该类使用IOptions <RouteOptions>参数初始化构造函数。

Microsoft.Extensions.Options程序集调用RouteOptions作为参数的MvcCoreRouteOptionsSetup.Configure方法。这将添加一个KnownRouteValueConstraint类型的约束映射到约束映射字典。当首次构建RouteOptions时，该字典将初始化多个默认约束。我会在以后的文章中详细介绍路由代码。

通过提供的名称和模板构建一个新的Route对象。在我们的例子中，新对象添到了RouteBuilder.Routes列表中。至此，在MvcSandbox示列程序运行时，我们的router builder就有了一条路由记录。

请注意，MvcApplicationBuilderExtensions类还包括一个名为UseMvcWithDefaultRoute的扩展方法。此方法会调用UseMvc，通过硬编码设定默认路由。

public static IApplicationBuilder UseMvcWithDefaultRoute(this IApplicationBuilder app)
{
    if (app == null)
    {
        throw new ArgumentNullException(nameof(app));
    }

    return app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

该路由使用与MvcSandbox程序中定义的相同名称和模板进行定义。因此，它可能被用作MvcSandbox Startup类中的轻微代码保护程序（slight code saver）。对于最基本的Mvc程序，使用该扩展方法可能足以满足路由的需求。但在大多实际使用场景中，我相信你会传递一套更加完整的路由。这是一个很好的方式（shorthand），如果你想从基本路由模板开始，就可以直接调用UseMvc()而不使用任何参数。

接下来，调用静态AttributeRouting.CreateAttributeMegaRoute方法，同时把生成的路由添加到RouteBuilder中的Routes List（索引位置为0）。CreateAttributeMegaRoute已在“Creates an attribute route using the provided services and provided target router”文中讲述，它看起来像这样：

public static IRouter CreateAttributeMegaRoute(IServiceProvider services)
{
    if (services == null)
    {
        throw new ArgumentNullException(nameof(services));
    }

    return new AttributeRoute(
        services.GetRequiredService<IActionDescriptorCollectionProvider>(),
        services,
        actions =>
        {
            var handler = services.GetRequiredService<MvcAttributeRouteHandler>();
            handler.Actions = actions;
            return handler;
        });
}

该方法创建了一个实现了IRoute接口的新AttributeRoute。其构造函数看起来想象这样：

public AttributeRoute(
    IActionDescriptorCollectionProvider actionDescriptorCollectionProvider,
    IServiceProvider services,
    Func<ActionDescriptor[], IRouter> handlerFactory)
{
    if (actionDescriptorCollectionProvider == null)
    {
        throw new ArgumentNullException(nameof(actionDescriptorCollectionProvider));
    }

    if (services == null)
    {
        throw new ArgumentNullException(nameof(services));
    }

    if (handlerFactory == null)
    {
        _handlerFactory = handlerFactory;
    }

    _actionDescriptorCollectionProvider = actionDescriptorCollectionProvider;
    _services = services;
    _handlerFactory = handlerFactory;
}

该构造函数需要一个IactionDescriptorCollectionProvider，一个IServiceProvider和一个接受ActionDescriptor数组参数，并返回IRouter的Func。默认情况下，通过AddMvc注册服务时将获得一个ActionDescriptorCollectionProvider实例，它是一个通过ServiceProvider注册的单例（singleton）对象。ActionDescriptors表示在应用程序中创建和发现可用的MVC actions。这些对象我们另文分析。

创建新的AttributeRoute代码（CreateAttributeMegaRoute方法内部）使用lambda来定义Func <ActionDescriptor []，IRouter>的代码。在这种情况下，委托函数从ServiceProvider请求一个MvcAttributeRouteHandler。因为被注册为transient，所以每次请求ServiceProvider将返回一个新的MvcAttributeRouteHandler实例。委托代码然后使用传入的ActionDescriptions数组在MvcAttributeRouteHandler上设置Actions属性（ActionDescriptions的数组），最后返回新的处理程序。

返回UserMvc，IapplicationBuilder中的UseRouter扩展方法完成调用。传递给UseRouter的对象是通过调用RouteBuilder的Build方法来创建的。该方法将添加路由到路由集合。RouteCollection内部将追踪哪些是已命名，哪些是未命名。在我们的MvcSandbox示例中，我们会得到一个命名为“default”的路由和一个未命名的AttributeRoute。

UseRouter有两个签名。此时我们传递一个IRouter，所以调用以下方法：

public static IApplicationBuilder UseRouter(this IApplicationBuilder builder, IRouter router)
{
    if (builder == null)
    {
        throw new ArgumentNullException(nameof(builder));
    }

    if (router == null)
    {
        throw new ArgumentNullException(nameof(router));
    }

    if (builder.ApplicationServices.GetService(typeof(RoutingMarkerService)) == null)
    {
        throw new InvalidOperationException(Resources.FormatUnableToFindServices(
            nameof(IServiceCollection),
            nameof(RoutingServiceCollectionExtensions.AddRouting),
            "ConfigureServices(...)"));
    }

    return builder.UseMiddleware<RouterMiddleware>(router);
}

该方法实现检查ServiceProvider中的RoutingMarkerService。假设这是按预期注册的，它将RouterMiddleware添加到中间件管道（middeware pipeline）中。正是这个中间件，使用IRouter来尝试将控制器的请求和MVC中的动作（action）进行匹配，以便处理它们。这个过程的细节将在未来的博文中展现。

到此，应用程序管道已配置，应用程序已准备好接收请求。本文也可以结束了。

小结

本文我们分析了UseMvc并且看到它设置了将在稍后使用的MiddlewareFilterBuilder。然后它还通过RouteBuilder获得一个IRouter，在这个阶段的大部分工作都是注册路由。一旦设置完成，路由中间件就被注册到管道中。这个代码（中间件）知道如何检查传入的请求，并将路径映射到适当的控制器和可以处理它们的操作。

configureRoutes(routes);

routes.Routes.Insert(0, AttributeRouting.CreateAttributeMegaRoute(app.ApplicationServices));

return app.UseRouter(routes.Build());

}