学习ASP.NET Core, 怎能不了解请求处理管道[4]: 应用的入口——Startup

一个ASP.NET Core应用被启动之后就具有了针对请求的处理能力，而这个能力是由管道赋予的，所以应用的启动同时意味着管道的成功构建。由于管道是由注册的服务器和若干中间件构成的，所以应用启动过程中一个核心的工作就是完成中间节的注册。由于依赖注入在ASP.NET Core应用这得到非常广泛的应用，框架绝大部分的工作都会分配给我们预先注册的服务，所以服务注册也是启动WebHost过程的另一项核心工作。这两项在启动过程中必须完成的核心工作通过一个名为Startup的对象来承载。 [本文已经同步到《ASP.NET Core框架揭秘》之中]

目录

一、 DelegateStartup
二、ConventionBasedStartup
    StartupMethods
    StartupLoader
    如何选择启动类型
    如何选择服务注册方法和中间件注册方法
    StartupMethods对象的创建
    UseStartup方法究竟做了些什么？
三、选择哪一个Startup

这里所谓的Startup实际上是对所有实现了IStartup接口的所有类型以及对应对象的统称。如下面的代码片段所示，服务注册由ConfigureServices方法来实现，它返回一个ServiceProvider对象，至于另一个方法Configure则负责完成中间件的注册，方法输入参数是一个ApplicationBuilder对象。

public interface IStartup
{
    IServiceProvider ConfigureServices(IServiceCollection services);
    void Configure(IApplicationBuilder app);
}

IStartup接口所在的NuGet包中还定义了另一个实现了这个接口的抽象类StartupBase。如下面的代码片段所示，StartupBase实现了抽象方法ConfigureServices，该方法直接利用提供的ServiceCollection对象创建返回的ServiceProvider。换句话说，派生于StartupBase的Startup类型如果没用重写ConfigureServices方法，它们实际上只关心中间件的注册，而不需要注册额外的服务。

public abstract class StartupBase : IStartup
{
    public abstract void Configure(IApplicationBuilder app);
    public virtual IServiceProvider ConfigureServices(IServiceCollection services)
    {
        return services.BuildServiceProvider();
    }
}

一、 DelegateStartup

我们来想想具体的应用中是如何注册中间件和服务的。中间件的注册可以采用两种方式，最简单的方式就是直接调用IWebHostBuilder的Configure方法。如下面的代码片段所示，这个方法直接上是借助于一个类型为Action<IApplicationBuilder>的委托对象将中间件注册到提供的ApplicationBuilder对象上。

public static class WebHostBuilderExtensions
{
    public static IWebHostBuilder Configure(this IWebHostBuilder hostBuilder, Action<IApplicationBuilder> configureApp);
}

new WebHostBuilder()
    .Configure(app => app
        .UseExceptionHandler("/Home/Error")
        .UseStaticFiles()
        .UseIdentity()
        .UseMvc())
    …

如果我们在应用中通过调用上面这个Configure方法来注册所需的中间件，WebHost在启动的时候会创建一个类型为DelegateStartup的Startup对象来完成真正的中间件注册工作。如下面的代码片段所示，DelegateStartup派生于StartupBase这个抽象类，它利用一个在构造时提供的Action<IApplicationBuilder>对象实现了Configure方法。很明显，我们调用IWebHostBuilder的Configure方法指定的Action<IApplicationBuilder>对象将用来创建这个DelegateStartup对象。

public class DelegateStartup : StartupBase
{
    private Action<IApplicationBuilder> _configureApp;

    public DelegateStartup(Action<IApplicationBuilder> configureApp)
    {
        _configureApp = configureApp;
    }

    public override void Configure(IApplicationBuilder app)
    {
        _configureApp(app);
    }
}

如下的代码片段体现了 IWebHostBuilder的扩展方法Configure的实现逻辑。如下面的代码片段所示，这个方法根据提供的Action<IApplicationBuilder>对象创建了一个DelegateStartup对象，并调用ConfigureServices方法以淡例模式注册到WebHostBuilder的服务集合中。这段代码还体现了另一个细节，除了进行Startup的服务注册之外，该方法还对“ApplicationName”选项（对应WebHostOptions的ApplicationName）进行了设置。

public static class WebHostBuilderExtensions
{
    public static IWebHostBuilder Configure(this IWebHostBuilder hostBuilder, Action<IApplicationBuilder> configureApp)
    {
        var startupAssemblyName = configureApp.GetMethodInfo().DeclaringType.GetTypeInfo().Assembly.GetName().Name;
        return hostBuilder
            .UseSetting("applicationName", startupAssemblyName)
            .ConfigureServices(svcs => svcs.AddSingleton<IStartup>(new DelegateStartup(configureApp));
    }
}

二、ConventionBasedStartup

我们知道应用中最常见的服务和中间件注册代码都定义在一个单独的类中，通常直接将其命名为Startup。为了与IStartup接口代表的Startup相区别，我们使用 “启动类（型）” 来称呼这个类。按照约定，启动类中会分别定义一个ConfigureServices和Configure方法来注册服务和中间件。一般情况下，这样的类型一般需要通过调用UseStartup<T>这个扩展方法注册到WebHostBuilder上。

public class Startup
{
    public void ConfigureServies(IServiceCollection services);
    public void Configure(IApplicationBuilder app);
}

new WebHostBuilder()
    .UseStartup<Startup>()
    …

如果我们在应用中将服务和中间件注册的实现定义在启动类型中，当WebHost被启动的时候，ASP.NET Core会创建一个类型为ConventionBasedStartup的Startup对象。这个Startup类型之所以采用这样的命名方式，是因为ASP.NET Core并没有采用接口实现的方式为启动类型做强制性的约束，而仅仅是为作为启动类型的定义提供了一个约定而已，至于具体采用怎样的约定，我们将在后续部分进行详细介绍。

StartupMethods

在了解了启动类型的约定以及常见的定义形式之外，我们现在来讨论这对这个类型创建的ConventionBasedStartup就是怎样的对象。从下面的代码片段可以看出，一个ConventionBasedStartup对象是根据一个类型为StartupMethods对象创建的。顾名思义，StartupMethods只在提供两个用户注册服务和中间件的方法，这两个方法体现在由它的两个属性（ConfigureServicesDelegate和ConfigureDelegate）提供的两个委托对象，这两个委托对象分别实现了定义在ConventionBasedStartup的ConfigureServices和Configure方法。

public class ConventionBasedStartup : IStartup
{
    public ConventionBasedStartup(StartupMethods methods);
    public IServiceProvider ConfigureServices(IServiceCollection services);
    public void Configure(IApplicationBuilder app);
}

public class StartupMethods
{
    public Func<IServiceCollection, IServiceProvider>     ConfigureServicesDelegate {  get; }
    public Action<IApplicationBuilder>                    ConfigureDelegate {  get; }

    public StartupMethods(Action<IApplicationBuilder> configure);
    public StartupMethods(Action<IApplicationBuilder> configure, Func<IServiceCollection, IServiceProvider> configureServices);
}

StartupLoader

既然ConventionBasedStartup对象是根据提供的一个StartupMethods对象创建的，那么现在的核心问题则变成了这个StartupMethods对象如何根据启动类型创建的。StartupMethods的创建者是一个类型为StartupLoader的对象，如下面的代码片段所示，StartupLoader定了两个名为FindStartupType和LoadMethods静态方法，前者用于启动类型的解析，后者则实现了StartupMethods对象的创建。

public class StartupLoader
{
    public static Type FindStartupType(string startupAssemblyName, string environmentName);
    public static StartupMethods LoadMethods(IServiceProvider services, Type startupType, string environmentName);
}

如何选择启动类型

如果启动类型没有通过调用WebHostBuilder的如下两个扩展方法UseStartup/UseStartup<TStartup>的显式注册，那么StartupLoader的FindStartupType方法会被调用来解析出正确的启动类型。这个方法具有两个参数，分别代表启动类型所在的程序集名称和当前环境名称，它们实际上对应着WebHostOptions的两个同名属性。当FindStartupType方法被执行并成功加载了提供的程序集之后，它会按照约定的启动类型全名从该程序集中加载启动类型，候选的启动类型全名按照选择优先级排列如下：

• Startup{EnvironmentName} （无命名空间）
• {StartupAssemblyName}.Startup{EnvironmentName}
• Startup（无命名空间）
• {StartupAssemblyName}.Startup{EnvironmentName}
• **. Startup{EnvironmentName}（任意命名空间）
• **. Startup（任意命名空间）

这个列表体现了启动类型解析过程中选择有效类型名称的一个基本策略，即“环境名称优先”和“无命名空间优先”。我们可以通过一个简单的实例来证明这个策略的存在。我们在一个ASP.NET Core控制台应用中添加一个名为“StartupLib”（程序集也采用这个名称）的类库项目，然后在这个项目中定义如下两组启动类，其中一组具有命名空间，另一组则采用程序集名称作为命名空间。这些启动类都派生于我们自定义的基类StartupBase，后者的Configure方法中注册了一个中间件将自身的类型作为响应内容。对于每组中的三个启动类，一个命名为Startup，另外两个则分别以环境名称（ “Development” 和 “Production” ）作为后缀。

public class StartupBase
{
    public void ConfigureServices(IServiceCollection services){}
    public void Configure(IApplicationBuilder app)
    {
        app.Run(async context => await context.Response.WriteAsync(this.GetType().FullName));
    }
}

public class Startup                : StartupBase{}
public class StartupDevelopment     : StartupBase{}
public class StartProduction        : StartupBase{}

namespace StartupLib
{
    public class Startup               : StartupBase{}
    public class StartupDevelopment    : StartupBase{}
    public class StartProduction       : StartupBase{}
}

我们采用如下的程序来启动一个ASP.NET Core应用。如下面的代码代码片段所示，我们在利用WebHostBuilder创建并启动WebHost之前，调用UseSettings方法以配置的形式指定了启动程序集（“StartupLib”）和当前运行环境（“Development”）的名称。

public class Program
{
    public static void Main()
    {
        new WebHostBuilder()
            .UseKestrel()
            .UseSetting("startupAssembly", "StartupLib")
            .UseSetting("environment", "Development")
            .Build()
            .Run();
    }
}

根据上述的启动类型解析规则，对于六个候选的启动类型，最终被选择的是不具有命名空间的StartupDevelopment类型。当应用启动之后，我们利用浏览器请求应用监听地址（“http://localhost:5000”），这个被选择的启动程序的名称将会以如下的形式直接显示出来。

如何选择服务注册方法和中间件注册方法

在了解了ASP.NET Core针对启动类型命名的约定之后，我们来讨论一下定义在启动类中用于注册服务和中间件的两个方法的约定。这两个方法可以是静态方法，也可以是实例方法。从方法命名来看，这两个方法除了命名为“ConfigureServices”和“Configure”之外，方法名还可以携带运行环境名称，具体采用的格式分别为“Configure{EnvironmentName}Services”和“Configure{EnvironmentName}”，后者具有更高的选择优先级。

ConfigureServices/Configure{EnvironmentName}Services方法具有一个类型为IServiceCollection接口的参数，表示存放注册服务的ServiceCollection对象。如过这个方法没有定义任何参数，它依然是合法的。一般来说，这个方法不具有返回值（返回类型为void），但是它也可以定义成一个返回类型为IServiceProvider的方法。如果这个方法返回一个ServiceProvider对象，后续过程中获取的所有服务将从这个ServiceProvider中提取。对于没有返回值的情况，系统会根据当前注册的服务创建一个ServiceProvider。

Configure/Configure{EnvironmentName}方法只要求只要求第一个参数类型采用IApplicationBuilder接口，至于这个方法可以包含多少个参数，各个参数应该具有怎样的类型，并未做任何规定。实际上我们为这个方法定义任意后续参数都是合法的。当ConventionBasedStartup在调用这个方法的时候，同样是采用依赖注入的方式来提供这些参数。如下面的代码片段所示，我们为启动类的Configure方法定义相应的参数来直接使用在ConfigureServices方法上注册的三个服务。

new WebHostBuilder()
    .ConfigureServices(services => services.AddSingleton<IFoobar, Foobar>())
    …

public class Startup
{
    public Startup(IFoobar foobar)
    {
        Debug.Assert(foobar.GetType() == typeof(Foobar));
    }
    public void ConfigureServies(IServiceCollection services) ;
    public void Configure(IApplicationBuilder app) ;
}

StartupMethods对象的创建

除此之外，对于定义成实例类型的启动类，我们并不要求它具有一个默认无参的构造函数。如果构造函数具有参数，ConventionBasedStartup在实例化的时候会采用构造函数注入的方式来提供构造函数的参数。至于提供参数所用的ServiceProvider，就是WebHostBuilder在创建WebHost对象时作为构造函数参数提供的那个ServiceProvider。如下面的代码片段所示，我们利用WebHostBuilder创建并启动WebHost之前，调用他的ConfigureServices方法针对接口IFoobar注册了一个服务，那么注册为启动类的Startup类可以在构造函数中以注入的形式使用这个服务对象。

public class StartupLoader
{
    public static StartupMethods LoadMethods(IServiceProvider serviceProvider, Type startupType, string environmentName)
    {
        return new StartupMethods(BuildConfigureDelegate(serviceProvider, startupType, environmentName),
            BuildConfigureServicesDelegate(serviceProvider, startupType,   environmentName));
    }

    private static Func<IServiceCollection, IServiceProvider> BuildConfigureServicesDelegate(IServiceProvider serviceProvider, Type startupType, string environmentName)
    {
        MethodInfo method = FindMethod(startupType, $"Configure{environmentName}Services", "ConfigureServices");
        object instance = method.IsStatic ? null : ActivatorUtilities.GetServiceOrCreateInstance(serviceProvider, startupType);
        return services =>
        {
            object[] arguments = method.GetParameters().Length > 0 ? new object[] { services } : new object[0];
            return (method.Invoke(instance, arguments) as IServiceProvider) ?? services.BuildServiceProvider();
        };
    }

    private static Action<IApplicationBuilder> BuildConfigureDelegate(IServiceProvider serviceProvider, Type startupType, string environmentName)
    {
        MethodInfo method = FindMethod(startupType, $"Configure{environmentName}", "Configure");
        object instance = method.IsStatic ? null : ActivatorUtilities.GetServiceOrCreateInstance(serviceProvider, startupType);
        object[] arguments = method.GetParameters().Select(p => serviceProvider.GetService(p.ParameterType)).ToArray();
        return app =>
        {
            arguments[0] = app;
            method.Invoke(instance, arguments);
        };
    }

    private static MethodInfo FindMethod(Type startupType, string method1, string method2)
    {
        BindingFlags bindAttribute = BindingFlags.Public | BindingFlags.Instance |    BindingFlags.Static;
        return startupType.GetMethod(method1, bindAttribute)?? startupType.GetMethod(method2, bindAttribute);
     }
}

UseStartup方法究竟做了些什么？

当我们调用IWebHostBuilder接口的扩展方法UseStartup/UseStartup<TStartup>注册某个启动类的时候，该方法会按照如下的形式创建一个ConventionBasedStartup对象并注册到WebHostBuilder的服务集合上。和上面介绍的Configure方法一样，UseStartup方法同样会设置 “ApplicationName” 选项。除此之外，这段还体现了另一个细节，那就是如果我们直接定义一个实现了IStartup接口的启动类，UseStartup方法会直接注册这个类型，而不会再多此一举地创建一个ConventionBasedStartup对象。

public static class WebHostBuilderExtensions
{
    public static IWebHostBuilder UseStartup<TStartup>(this IWebHostBuilder hostBuilder) where TStartup : class
    {
        return UseStartup(hostBuilder, typeof(TStartup));
    }

    public static IWebHostBuilder UseStartup(this IWebHostBuilder hostBuilder, Type startupType)
    {
        var startupAssemblyName = startupType.GetTypeInfo().Assembly.GetName().Name;
        return hostBuilder
            .UseSetting("ApplicationName", startupAssemblyName)
            .ConfigureServices(svcs =>
            {
                if (typeof(IStartup).IsAssignableFrom(startupType))
                {
                    svcs.AddSingleton(typeof(IStartup), startupType);
                }
                else
                {
                    svcs.AddSingleton<IStartup>(sp => new ConventionBasedStartup(StartupLoader.LoadMethods(sp, startupType, sp.GetService<IHostingEnvironment>().EnvironmentName)));
                }
            });
    }
}

三、选择哪一个Startup

应用启动的时候，Startup帮助我们完成所需服务和中间件的注册，而Startup对象自身也是服务的形式被注册到WebHostBuilder或者WebHost的服务集合中。总的来说，Startup的注册具有如下三种途径：

• 调用IWebHostBuilder的扩展方法Configure方法创建并注册一个DelegateStartup对象。
• 调用IWebHostBuilder的扩展方法UseStartup或者UseStartup<TStartup>创建并注册一个ConventionBasedStartup对象。
• 如果设置了启动程序集名称（对应WebHostOptions的StartupAssembly属性）并且对应的程序集中存在一个满足约定的启动类型，也会创建并注册一个ConventionBasedStartup对象。

那么现在的问题来说，如果我们采用上述这三种途径创建并注册了多个Startup，那么系统是只选择其中一个，还是所有的Startup均有效呢？就如下这段程序来说，如果当前程序集同时定义了三个有效的Startup类型（Startup、Startup1和Startup2），最终将会有五个Startup对象被注册，其中两个是通过Configure方法注册的DelegateStartup对象，对于额外三个ConventionBasedStartup对象来说， 其中两个针对显式指定的启动类型（Startup1和Startup2），另外一个则是针对默认的约定解析出来的启动类型（Startup）。对于这个五个Startup对象，究竟哪些是有效的呢？

new WebHostBuilder()
    .Configure(app => {})
    .Configure(app => {})
    .UseStartup<Startup1>()
    .UseStartup<Startup2>()
    .UseSetting("startupAssembly", Assembly.GetEntryAssembly().FullName)
…

不论我们注册多少个Startup，系统最终都只会其中一个来注册服务和中间件。由于WebHost会直接利用ServiceProvider来获取Startup对象，根据 “后来居上” 的原则，最终选择的总是最后注册的那个Startup。由于Configure方法和UseStartup方法最终都是调用WebHostBuilder的ConfigureServices方法进行服务注册，所以最后调用的方法具有最高的优先级。至于根据指定启动程序集名称而创建出来的ConventionBasedStartup，针对它的注册信息会放在最前面，所以具有最低优先级。根据这个策略，上面这段程序最终选择的启动类是Startup2。