ASP.NET Core应用启动初始化有哪些N种方案？

[接上篇]“天下大势，分久必合，合久必分”，ASP.NET应用通过GenericWebHostService这个承载服务被整合到基于IHostBuilder/IHost的服务承载系统中之后，也许微软还是意识到Web应用和后台服务的承载方式还是应该加以区分，于是推出了基于WebApplicationBuilder/WebApplication的承载方式。我们可以将其称为第三代承载模式，它有一个官方的名称叫做“Minimal API”。Minimal API同样面临向后兼容的问题，而且这次需要同时兼容前面两代承载模式，所以我们会发现“上篇”中提到的一系列初始化操作有了更多实现方式。[本文部分内容来源于《ASP.NET Core 6框架揭秘》第15章] 目录 一、Minimal API 二、推荐编程方式 三、承载环境 四、承载配置 五、应用配置 六、服务注册 七、中间件注册 八、Startup类型不再被支持 一、Minimal API基于Minimal API的第三代应用承载方式的推出并非又回到了起点，因为底层的承载方式其实没有改变，它只是在上面再封装了一层而已。新的应用承载方式依然采用“构建者（Builder）”模式，核心的两个对象分别为WebApplication和WebApplicationBuilder，代表承载应用的WebApplication对象由WebApplicationBuilder对象进行构建。第二代承载模式需要提供针对IWebHostBuilder接口的兼容，作为第三代承载模式的Minimal API则需要同时提供针对IWebHostBuilder和IHostBuilder接口的兼容，此兼容性是通过这两个接口的实现类型ConfigureWebHostBuilder和ConfigureHostBuilder达成的。 WebApplicationBuilder类型的WebHost和Host属性返回了这两个对象，之前定义在IWebHostBuilder和IHostBuilder接口上的绝大部分API（并非所有API）借助它们得以复用。也正是有了这段历史，我们会发现相同的功能具有两到三种不同的编程方式。比如IWebHostBuilder和IHostBuilder接口上都提供了注册服务的方法，而WebApplicationBuilder类型利用Services属性直接将存放服务注册的IServiceCollection对象暴露出来，所以任何的服务注册都可以利用这个属性来完成。 public sealed class WebApplicationBuilder { public ConfigureWebHostBuilder WebHost { get; } public ConfigureHostBuilder Host { get; } public IServiceCollection Services { get; } public ConfigurationManager Configuration { get; } public ILoggingBuilder Logging { get; } public IWebHostEnvironment Environment { get; } public WebApplication Build(); } public sealed class ConfigureWebHostBuilder : IWebHostBuilder, ISupportsStartup public sealed class ConfigureHostBuilder : IHostBuilder, ISupportsConfigureWebHost IWebHostBuilder和IHostBuilder接口都提供了设置配置和日志的方法，这两方面的设置都可以利用WebApplicationBuilder利用Configuration和Logging暴露出来的ConfigurationManager和ILoggingBuilder对象来实现。既然我们采用了Minimal API，那么我们就应该尽可能得使用WebApplicationBuilder类型提供的API。 二、推荐编程方式我们再次使用[上篇]提供的实例来演示承载配置、应用配置、承载环境、服务注册和中间件在Minimal API下的标准编程方式。该演示实例会注册如下这个FoobarMiddleware中间件，后者利用注入的IHandler服务完成请求的处理工作。