1. 入口文件
一个应用程序总有一个入口文件,是应用启动代码开始执行的地方,这里往往也会涉及到应用的各种配置。当我们接触到一个新框架的时候,可以从入口文件入手,了解入口文件,能够帮助我们更好地理解应用的相关配置以及应用的工作方式。
.Net Core 应用的入口文件是 Program.cs,这里是应用启动的地方。在 .Net 6 之前的版本,Program.cs 文件是下面这样的,这是创建一个 Web 项目时的默认代码。
public class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args).Build().Run();
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
}
其中 Main 方法就是应用启动的入口。可以看到在应用启动的时候,通过 建造者模式 创建了一个主机,并进行了相关的配置,最后将其运行起来。
从代码中可以看到,在对主机进行配置的时候,使用到了 Startup 类,在 .Net 6 之前的版本,Startup 类承担应用的启动任务,是应用配置的主要地方。
2. Startup 类
2.1 Startup类结构
Startup 类支持两种定义方式,一种是实现 IStartup 接口,一种是基于约定的。无论哪一种,Startup 类的基本结构都包含以下两个个关键函数。整体来说,基于约定的 Startup 类更加灵活。
- ConfigureServices方法
- Configure方法
2.1.2 ConfigureServices 方法
- 该方法是可选的
- 该方法用于添加服务到DI容器中
- 该方法在 Configure 方法之前被调用
- 基于约定的情况下,该方法要么无参数,要么只能有一个参数且类型必须为 IServiceCollection
- 该方法内的代码大多是形如
Add{Service}
的扩展方法
2.1.3 Configure方法
- 该方法是必须的
- 该方法用于配置 HTTP 请求管道,通过向管道添加中间件,应用不同的响应方式。
- 该方法在 ConfigureServices 方法之后被调用
- 基于约定的情况下,该方法中的参数可以接受任何已注入到DI容器中的服务
- 该方法内的代码大多是形如
Use{Middleware}
的扩展方法 - 该方法内中间件的注册顺序与代码的书写顺序是一致的,先注册的先执行,后注册的后执行
另外还有构造函数,当使用通用主机时,Startup 构造函数支持注入以下三种服务类型,在 Startup 类中全局进行使用:
- IConfiguration
- IWebHostEnvironment
- IHostEnvironment
2.2 缺省Startup
所谓缺省Startup,就是应用启动配置不用 Startup 类,直接在 ConfigureWebHostDefaults 中进行配置。
publicstaticIHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
// ConfigureServices 可以调用多次,最终会将结果聚合
webBuilder.ConfigureServices(services =>
{
})
// Configure 如果调用多次,则只有最后一次生效.
.Configure(app =>
{
// Configure调用之前,ConfigureServices已经调用,容器对象已经生成,所以这里可以通过容器直接解析需要的对象
var env = app.ApplicationServices.GetRequiredService<IWebHostEnvironment>();
});
});
2.3 多环境配置
.NET Core 框架支持多环境开发,可以通过环境变量 ASPNETCORE_ENVIRONMENT
来设置应用当前的运行环境,以实现一套代码在不同环境下运行,根据环境区分一定的行为,支持开发、测试、预发布、生成环境下不同条件、不同配置的运行场景。
我们可以直接在机器的环境变量中进行设置,在项目的 Properties 文件夹里面的“launchSettings.json”文件进行配置,该文件是用于配置VS中项目启动的,在 profiles 节点中通过不同的 json 对象配置当前应用的启动模式,而描述启动模式的 json 对象支持的字段中有一个 environmentVariables
节点,可以通过键值对方式配置环境变量。
这里配置的环境变量只会在当前项目中起作用。若应用运行环境中从未对 ASPNETCORE_ENVIRONMENT 环境变量进行配置,则默认为 Production 。而我们其实可以将 ASPNETCORE_ENVIRONMENT 设置为任意值。
之后,这些环境变量会在主机初始化的时候作为主机配置被加载到应用中,这些会在后面的配置系统中详细讲到。而在代码中,我们可以通过注入 IWebHostEnvironment 服务获取到当前应用的运行环境。例如下面在 StartUp 中通过判断环境执行不同的应用初始化逻辑。
IWebHostEnvironment 服务中默认提供对 Development、Production、Staging 三种环境进行判断的扩展方法,如果是其他自定的环境,如 Test,可以使用 IsEnviroment() 方法进行判断。
通过 IWebHostEnvironment 判断不同环境,从而在 StartUp 类中使用不同的初始化初始化逻辑,这种方式适合于不同环境下代码差异较少的情况。除此之外还有两种基于约定的方式,分别是 Startup 方法约定 和 StartUp 类名约定 。
StartUp 方法约定具体是指 StartUp 类中 ConfigureServices 和 Configure 方法还可以按照Configure{EnvironmentName}Services和Configure{EnvironmentName}Services 这样的命名格式来写,通过命名约定的 {EnvironmentName} 部分区分不同环境,装载不同环境的代码。
如果 StartUp 类中存在与当前环境名称匹配的 Configure{EnvironmentName}Services和Configure{EnvironmentName}Services 方法的话,则应用启动时会执行相应的方法中的逻辑,如果没有则执行原始的 ConfigureServices 和 Configure 方法中的逻辑。
通过查看源码,可以看到当我们明确配置一个 Startup 类作为应用启动类的时候,会先判断是否是实现了 IStartup 接口。
如果没有的话,则通过 StartupLoader 判断 Startup 类是否符合约定,最终构建出实现了 IStartup 接口的ConventionBasedStartup,并注入到容器中。这时候会结合环境变量,优先获取带有环境变量的方法,如果没有则使用没有带环境变量的方法。
而 StartUp 类名约定和方法约定类似,程序启动时,会优先寻找当前环境命名符合Startup{EnvironmentName}的 Startup 类,如果找不到,则使用名称为Startup的类。类名约定的方式适用于多环境下,代码差异较大的情况。
类名约定的方式下,在配置使用 UseStartUp 的时候需要一点小改动:
查看源码,可以看到在我们调用上面的方法的时候,实际上并没有做具体的 Startup 类的构建操作,只是写入了两个设置,其实就是写入到了配置系统中,其中 WebHostDefaults.StartupAssemblyKey 是关键。
之后在我们应用启动,调用Build方法时,在构建ASP.NET Core 基本服务的时候才会根据设置去构建启动类。
在这里通过 StartupLoader 结合环境名称查找程序集中符合约定的 Startup 类。