.NET CORE Startup

而Host的主要的职责就是Web Server的配置和Pilpeline（请求处理管道）的构建。

这张图描述了一个总体的启动流程，从上图中我们知道ASP.NET Core应用程序的启动主要包含三个步骤：

CreateDefaultBuilder()：创建IWebHostBuilder
Build()：IWebHostBuilder负责创建IWebHost
Run()：启动IWebHost

所以，ASP.NET Core应用的启动本质上是启动作为宿主的WebHost对象。
其主要涉及到两个关键对象IWebHostBuilder和IWebHost，它们的内部实现是ASP.NET Core应用的核心所在。
————————————————
版权声明：本文为CSDN博主「kalvin_y_liu」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kalvin_y_liu/article/details/122796793

在这里插入图片描述

在这里插入图片描述
从上图中我们可以看出CreateDefaultBuilder()方法主要干了六件大事：

UseKestrel：使用Kestrel作为Web server。
UseContentRoot：指定Web host使用的content
root（内容根目录），比如Views。默认为当前应用程序根目录。
ConfigureAppConfiguration：设置当前应用程序配置。主要是读取 appsettinggs.json
配置文件、开发环境中配置的UserSecrets、添加环境变量和命令行参数。
ConfigureLogging：读取配置文件中的Logging节点，配置日志系统。
UseIISIntegration：使用IISIntegration 中间件。
UseDefaultServiceProvider：设置默认的依赖注入容器。
创建完毕WebHostBuilder后，通过调用UseStartup()来指定启动类，来为后续服务的注册及中间件的注册提供入口。

————————————————
版权声明：本文为CSDN博主「kalvin_y_liu」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/kalvin_y_liu/article/details/122796793

.NET Core中ConfigureServices与Configure区别

Startup中经常看到这个两个ConfigureServices与Configure,
ConfigureServices 用于配置依赖注入以在运行时根据依赖关系创建对象，Configure 用于配置中间件以构建请求处理流水线。

This method gets called by the runtime. Use this method to configure
the HTTP request pipeline.
此方法由运行时调用。使用此方法配置HTTP请求管道。
This method gets called by the runtime. Use this method to add
services to the container.
此方法由运行时调用。使用此方法将服务添加到容器。

在这里插入图片描述

生命周期

ConfigureServices

ConfigureServices 是用来将服务注册到 DI 容器用的。这个方法可不实现，并不是必要的方法。

Configure
这个是必要的方法，一定要实现。但 Configure 方法的参数并不固定，参数的实例都是从 WebHost 注入进来，可依需求增减需要的参数。
IApplicationBuilder 是最重要的参数也是必要的参数，Request 进出的 Pipeline 都是通过 ApplicationBuilder 来设置。

经常看到这个两个ConfigureServices与Configure,对于它们的用法总是说不清道不明，下面看了微软官方文档，再次记录总结下

简单的说
1.Configure配置请求管道
2.ConfigureServices配置服务
在这里插入图片描述

扫描二维码关注公众号，回复： 14906226 查看本文章

常见的配置

1.Configure在请求管道中配置中间件

并非每个中间件都需要按照这个确切顺序进行，但是很多中间件都需要遵循这个顺序。
例如UseCors，UseAuthentication和UseAuthorization必须按照显示的顺序。

》》异常/错误处理
》》HTTPS重定向中间件（UseHttpsRedirection）将HTTP请求重定向到HTTPS。
》》静态文件中间件（UseStaticFiles）返回静态文件，并使进一步的请求处理短路。
》》Cookie政策中间件（UseCookiePolicy）使该应用符合EU通用数据保护法规（GDPR）法规。
》》路由中间件（UseRouting）路由请求。
》》身份验证中间件（UseAuthentication）尝试在允许用户访问安全资源之前对其进行身份验证。
》》授权中间件（UseAuthorization）授权用户访问安全资源。
》》会话中间件（UseSession）建立并维护会话状态。如果应用使用会话状态，请在Cookie策略中间件之后和MVC中间件之前调用会话中间件。
》》端点路由中间件（UseEndpoints带有MapRazorPages）将Razor Pages端点添加到请求管道。

2.ConfigureServices配置服务
AddLocalization 添加本地化方法
AddLogging 添加记录方法
AddStackExchangeRedis 添加Redis缓存服务
用于配置依赖注入（定义接口；通过依赖注入框架注册对象；通过构造函数创建对象。）等等……
注意:
ConfigureServices是可选方法，Configure是必须要有的方法
执行顺序：先执行ConfigureServices, 在执行Configure

Middleware 概念

ASP.NET Core在Middleware的官方说明中，使用了Pipeline这个名词，意指Middleware像水管一样可以串联在一起，所有的Request及Response都会层层经过这些水管。
用图例可以很容易理解，如下图：
在这里插入图片描述

DI ioc

ASP.NET Core使用了大量的依赖注入(Dependency Injection, DI)，把控制反转(Inversion Of Control, IoC)运用的相当巧妙。DI可算是ASP.NET Core最精华的一部分，有用过Autofac或类似的DI Framework对此应该不陌生。
本篇将介绍ASP.NET Core的依赖注入(Dependency Injection)。

DI 容器介绍
在没有使用DI Framework 的情况下，假设在UserController 要调用UserLogic，会直接在UserController 实例化UserLogic，如下：

public class UserLogic {
    
    
    public void Create(User user) {
    
    
        // ...
    }
}
 
public class UserController : Controller {
    
    
    public void Register(User user){
    
    
        var logic = new UserLogic();
        logic.Create(user);
        // ...
    }
}

以上程序基本没什么问题，但是依赖关系差了点。UserController 必须要依赖UserLogic才可以运行，拆出接口改成：

public interface IUserLogic {
    
    
    void Create(User user);
}
 
public class UserLogic : IUserLogic {
    
    
    public void Create(User user) {
    
    
        // ...
    }
}
 
public class UserController : Controller {
    
    
    private readonly IUserLogic _userLogic;
 
    public UserController() {
    
    
        _userLogic = new UserLogic();
    }
 
    public void Register(User user){
    
    
        _userLogic.Create(user);
        // ...
    }
}

UserController 与UserLogic 的依赖关系只是从Action 移到构造方法中，依然还是很强的依赖关系。

ASP.NET Core透过DI容器，切断这些依赖关系，实例的产生不在使用方(指上例UserController构造方法中的new)，而是在DI容器。
DI容器的注册方式也很简单，在Startup.ConfigureServices注册。如下：

Startup.cs

// ...
public class Startup
{
    
    
    public void ConfigureServices(IServiceCollection services)
    {
    
    
        // ...
        services.AddScoped<ISample, Sample>();
    }
}

第一个泛型为注入的类型
建议用Interface来包装，这样在才能把依赖关系拆除。
第二个泛型为实例的类型
DI 运行方式
ASP.NET Core的DI是采用Constructor Injection，也就是说会把实例化的物件从建构子传入。
如果要取用DI容器内的物件，只要在建构子加入相对的Interface即可。例如：

Controllers\HomeController.cs

using Microsoft.AspNetCore.Mvc;
using MyWebsite.Models;
 
namespace MyWebsite.Controllers
{
    
    
    public class HomeController : Controller
    {
    
    
        private readonly ISample _sample;
 
        public HomeController(ISample sample)
        {
    
    
            _sample = sample;
        }
 
        public string Index()
        {
    
    
            return $"[ISample]\r\n"
                 + $"Id: {
      
      _sample.Id}\r\n"
                 + $"HashCode: {
      
      _sample.GetHashCode()}\r\n"
                 + $"Tpye: {
      
      _sample.GetType()}";
        }
    }
}

ASP.NET Core 实例化Controller 时，发现构造方法中有ISample 这个类型的参数，就把Sample 的实例注入给该Controller。

每个Request 都会把Controller 实例化，所以DI 容器会从构造方法注入ISample 的实例，把sample 存到变量_sample 中，就能确保Action 能够使用到被注入进来的ISample 实例。

注入实例过程，情境如下：
在这里插入图片描述

Application Lifetime

除了程序进入点外，WebHost的启动和停止也是网站事件很重要一环，ASP.NET Core不像ASP.NET MVC用继承的方式捕捉启动及停止事件，而是透过Startup.Configure注入IApplicationLifetime来补捉Application启动停止事件。

IApplicationLifetime有三个注册监听事件及终止网站事件可以触发。如下：

public interface IApplicationLifetime
{
    
    
  CancellationToken ApplicationStarted {
    
     get; }
  CancellationToken ApplicationStopping {
    
     get; }
  CancellationToken ApplicationStopped {
    
     get; }
  void StopApplication();
}

ApplicationStarted
当WebHost启动完成后，会执行的启动完成事件。
ApplicationStopping
当WebHost触发停止时，会执行的准备停止事件。
ApplicationStopped
当WebHost停止事件完成时，会执行的停止完成事件。
StopApplication
可以通过此方法主动触发终止网站。
Service 生命周期
注册在DI 容器的Service 分三种生命周期：

Transient
每次注入时，都重新new一个新的实例。
Scoped
每个Request都重新new一个新的实例，同一个Request不管经过多少个Pipeline都是用同一个实例。上例所使用的就是Scoped。
Singleton
被实例化后就不会消失，程式运行期间只会有一个实例。