Une brève discussion sur l'explication détaillée du middleware ASP.NET Core et la pratique du projet

Avant-propos

Cet article est en fait utilisé par nous dans le développement de nos propres projets. Il est plus adapté aux applications pratiques. Il peut être considéré comme une utilisation approfondie du middleware, pas un simple Hello World.

Le rôle du middleware

Nous savons que tout framework Web encapsule les requêtes http dans un pipeline, et chaque requête passe par le pipeline. Une série d'opérations arrive finalement au code que nous avons. a écrit. Le middleware est ensuite un composant du pipeline d'application utilisé pour intercepter le processus de demande et effectuer d'autres traitements et réponses. Il peut y avoir de nombreux middlewares, et chaque middleware peut intercepter les requêtes dans le pipeline, et il peut décider de transférer ou non la requête vers le middleware suivant.

asp.net core fournit l'interface IApplicationBuilder pour enregistrer le middleware dans les requêtes du pipeline asp.net. Le middleware est une application AOP typique.
Chaque middleware peut fonctionner avant et après la requête. Une fois le traitement de la demande terminé, il est transmis à la demande suivante.

Comment fonctionne le middleware

Par défaut, l'ordre d'exécution du middleware est basé sur l'ordre enregistré dans la méthode public void Configure(IApplicationBuilder app){} dans le fichier Startup.cs.

Il existe environ 3 façons d'enregistrer un "middleware" dans le pipeline

1.app.Use(), l'interface IApplicationBuilder est fournie nativement et elle est utilisée pour l'inscription, etc.

2.app.Run() est une méthode d'extension. Elle nécessite un délégué RequestDelegate, qui contient des informations de contexte Http. Il n'y a pas de paramètre suivant car il est toujours exécuté à la dernière étape du pipeline. .

3.app.Map() est également une méthode d'extension, similaire au routage MVC. Elle est généralement utilisée pour traiter certains chemins de requêtes spéciaux. Par exemple : www.example.com/token etc.

Les Run et Map ci-dessus appellent également Use en interne, qui est une extension de l'interface IApplicationBuilder. Si vous pensez que le nom n'est pas assez précis, alors la méthode d'extension suivante est le middleware d'enregistrement authentique et est également la plus. puissant.

app.UseMiddlewarea8093152e673feb7aba1828c43532094(), oui, c'est tout. Pourquoi dit-on qu’il est puissant ? Parce qu'il fournit non seulement la fonction d'enregistrement du middleware, mais fournit également la fonction d'injection de dépendances (DI), qui sera utilisée dans la plupart des situations à l'avenir.

La différence entre middleware et filtre

Les étudiants qui connaissent le framework MVC doivent savoir que MVC fournit également 5 filtres principaux que nous pouvons utiliser pour traiter les requêtes et qui doivent être exécutés avant et après code. Il s'agit d'AuthentificationFilter, AuthorizationFilter, ActionFilter, ExceptionFilter et ResultFilter.

D'après la description, on voit que les fonctions du middleware et des filtres sont similaires, alors quelle est la différence entre eux ? Pourquoi créer un autre middleware ?
En fait, les filtres et les middlewares ont des objectifs différents, ce qui signifie qu'ils ont des responsabilités différentes et font des choses différentes.

Par exemple, le middleware est comme le Warglaive d'Azzinoth, le filtre est comme la Colère du Dragon, le Bâton d'Âme de Tarecgosa, vous êtes un guerrier tenant la Colère du Dragon, le bâton porteur d'âme de Tai Legosa va sur le champ de bataille pour tuer des gens. Bien que cela fasse des dégâts, les dégâts que vous infligez avec le bâton sont non seulement faibles, mais réduisent également les attributs.

En tant que deux outils AOP, le filtre est plus adapté à l'entreprise. Il se concentre sur l'application elle-même. Par exemple, si vous regardez ActionFilter et ResultFilter, ils interagissent directement avec votre Action et ActionResult. de votre part ? Cela semble très proche. Ensuite, j'ai certaines choses à faire, comme formater mes résultats de sortie et vérifier les données de mon ViewModel demandé, je dois utiliser Filter. Il fait partie de MVC et peut intercepter certaines informations sur votre contexte d'action, mais le middleware n'a pas cette capacité.

Quand avons-nous besoin d'un middleware ?

Alors, quand devons-nous utiliser un middleware ? Je crois comprendre que certaines choses qui doivent être faites dans le pipeline et qui ont peu à voir avec l'entreprise peuvent être utilisées dans nos applications, telles que l'authentification, le stockage de session, la journalisation, etc. En fait, notre projet principal asp.net lui-même contient déjà de nombreux middlewares.

Par exemple, lorsque nous créons une nouvelle application principale asp.net, parmi les modèles générés par défaut

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
  app.UseDeveloperExceptionPage();
   
  app.UseStaticFiles();
   
  loggerFactory.AddConsole();
   
  app.UseMvc(routes =>
  {
    routes.MapRoute(
      name: "default",
      template: "{controller=Home}/{action=Index}/{id?}");
  });
}

sont trop paresseux pour télécharger Le code source est disponible, nous utilisons Reflector pour afficher le code source :

//扩展方法`app.UseDeveloperExceptionPage();`
public static class DeveloperExceptionPageExtensions
{
  // Methods
  public static IApplicationBuilder UseDeveloperExceptionPage(this IApplicationBuilder app)
  {
    if (app == null)
    {
      throw new ArgumentNullException("app");
    }
    return UseMiddlewareExtensions.UseMiddleware<DeveloperExceptionPageMiddleware>(app, Array.Empty<object>());
  }
}

//扩展方法`app.UseStaticFiles();`
public static class StaticFileExtensions
{
  // Methods
  public static IApplicationBuilder UseStaticFiles(this IApplicationBuilder app)
  {
    if (app == null)
    {
      throw new ArgumentNullException("app");
    }
    return UseMiddlewareExtensions.UseMiddleware<StaticFileMiddleware>(app, Array.Empty<object>());
  }
}

Vous pouvez voir l'application .UseDeveloperExceptionPage(), app .UseStaticFiles() et ainsi de suite sont tous implémentés via un middleware.

Comment personnaliser votre propre middleware

Contexte : Le scénario dans lequel le middleware est utilisé dans notre projet est que nous devons partager les informations sur l'utilisateur (Utilisateur) avec d'autres départements. En prenant la plate-forme et le sous-système comme exemple, nous développons un sous-système dans lequel les informations sur les utilisateurs, la connexion, l'enregistrement et d'autres fonctions sont placées sur la plate-forme. Il s'agit d'un système multilingue. La plate-forme est développée en langage Java. accéder au sous-système. Certaines pages doivent vérifier si vous êtes connecté, et d'autres pages n'ont pas besoin de vérifier si vous êtes connecté, un système de vérification d'identité est donc nécessaire pour remplacer la fonction d'identité.

幸运的是微软已经给我们提供了一套身份验证的中间件，在Microsoft.AspNetCore.Authentication命名空间下，我们只需要拓展，添加自己的功能就行了 。具体怎么做呢？直接看代码吧。

根据约定俗成，中间件类需要有一个Invoke方法，签名是public async Task Invoke(HttpContext context){}，下面是一个中间件的示例类：

public class RequestLoggerMiddleware
{
  private readonly RequestDelegate _next;
  private readonly ILogger _logger;
 
  public RequestLoggerMiddleware(RequestDelegate next, ILoggerFactory loggerFactory)
  {
    _next = next;
    _logger = loggerFactory.CreateLogger<RequestLoggerMiddleware>();
  }
 
  public async Task Invoke(HttpContext context)
  {
    _logger.LogInformation("Handling request: " + context.Request.Path);
    await _next.Invoke(context);
    _logger.LogInformation("Finished handling request.");
  }
}

   

了解了上面的约定之后，我们就开始定义我们自己的中间件Class。

我们需要一个流程图来理清逻辑思路，以便于写代码的时候思路更加的清晰。

平台有一个要求就是，用户在我们子系统退出之后，要调用平台的一个接口通知他们，他们要做一些后续的业务。

OK，开始撸码。

首先创建一个PlatformAuthoricationMiddleware，它继承于Microsoft.AspNetCore.Authentication下的类AuthenticationMiddleware，由于AuthenticationMiddleware已经实现了Invoke功能，所以我们只需要重写(override)它里面的一些方法就可以了。等等，我们好像还需要一些配置，比如流程图中的ReturnUrl，平台的Cookie的Key值，平台验证用户合法性的接口地址等参数。

建立一个Options类进行配置的设置，我们取名字为：PlatformAuthenticationOptions，继承AuthenticationOptions，并且实现掉IOptions8742468051c85b06f0a0af9e3e506b5c接口，这样子就能在Startup中直接配置了。

我们只需要重写AuthenticationMiddleware中的CreateHandler方法就行了，在Handler中可以实现掉我们中间件的功能。

然后创建一个处理的Handler类，取名为PlatformAuthenticationHandler，继承于AuthenticationHandler58fec2039d3938dc329cad313e09b70a用来处理请求中的调用。

至此，我们的核心需要的类已经建立完了，剩下的就是填充代码。

1.在PlatformAuthenticationHandler中重写HandleAuthenticateAsync()方法 ， 进行主流程的控制。

2.在PlatformAuthenticationHandler中重写FinishResponseAsync()方法，进行Session的存储操作。

3.在PlatformAuthenticationHandler中重写HandleSignOutAsync()方法，进行登出的控制，因为用户登出之后我们要通知平台做一些其他操作。

4.在PlatformAuthenticationHandler中重写HandleUnauthorizedAsync()方法，进行未认证操作。

最后，我们需要一个扩展类来把我们的中间件以扩展方法注册到管道当中去 。

public static class MiddlewareExtensions
{
  public static IApplicationBuilder UsePlatformAuthentication(this IApplicationBuilder app) {
    if (app == null) {
      throw new ArgumentNullException(nameof(app));
    }
 
    return app.UseMiddleware<PlatformAuthenticationMiddleware>();
  }
 
  public static IApplicationBuilder UsePlatformAuthentication(this IApplicationBuilder app, CookieAuthenticationOptions options) {
    if (app == null) {
      throw new ArgumentNullException(nameof(app));
    }
    if (options == null) {
      throw new ArgumentNullException(nameof(options));
    }
 
    return app.UseMiddleware<PlatformAuthenticationMiddleware>(Options.Create(options));
  }
}

   

在Startup中就是app.UsePlatformAuthentication()

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) {
  loggerFactory.AddConsole(Configuration.GetSection("Logging"));
 
  //注册PlatformAuthentication中间件
  app.UsePlatformAuthentication(new PlatformAuthenticationOptions() {
    UserSessionStore = new UserSessionStore(),
  });
 
  app.UseMvc();
}

   

现在，我们的中间件核心业务流程的实现已经出来了，我就不大篇幅的粘贴代码了，会影响阅读，感兴趣具体实现的朋友可以去下面的地址查看代码，有具体流程的注释。

以上就是本文的全部内容，希望对大家的学习有所帮助，更多浅谈ASP.NET Core 中间件详解及项目实战相关文章请关注PHP中文网！