ASP.NET Core 에서 합 격 된 미들웨어 를 어떻게 만 드 는 지 자세히 알 아 보 세 요.

이 글 은 서로 다른 요청 에 대해 서로 다른 미들웨어 를 사용 하도록 했다.그러면 우 리 는 어떻게 ASP.NET Core 미들웨어 를 설정 해 야 합 니까?사실 중간 부품 은 ASP.NET Core 에서 웹 요청 을 처리 하 는 파이프 일 뿐이다.모든 ASP.NET Core 응용 프로그램 은 요청 에 응답 하기 위해 최소한 하나의 미들웨어 가 필요 하 며,응용 프로그램 은 실제 미들웨어 의 집합 일 뿐 입 니 다.물론 MVC 관 로 는 그 자체 가 미들웨어 이다.웹 폼 시대 에 Http Modules,Http Handler 가 나 타 났 다.그 때 는 내 가 그들 을 통 해 나의 광고 시스템 을 조직 한 것 을 유유히 기억 하고 우 리 를 계속 잡담 하지 않 았 다.
모든 미들웨어 구성 요 소 는 HttpContext 인 자 를 가 진 Invoke 방법 이 있 습 니 다.이 매개 변 수 를 사용 하여 처리 할 수 있 습 니 다.

public async Task Invoke(HttpContext context)
{
 if (context.Request.Path...)
 {
  await context.Response.WriteAsync("writing text...");
 }
}

응용 프로그램의 맨 위 에 있 는 미들웨어 는 모든 요청 에 대해 호출 될 것 입 니 다.이것 은.NET 프레임 워 크 가 자동 으로 완성 한 것 이다.중간 부품 은 클 라 이언 트 에 응답 을 보 낼 수도 있 고 다음 중간 부품 을 호출 할 수도 있다.다음 선택 에 대해 서 는 다음 미들웨어 구성 요소 에 접근해 야 합 니 다.대부분의 미들웨어 구성 요 소 는 RequestDelegate 인 자 를 가 진 구조 함 수 를 사용 하 는 이유 입 니 다.한 마디 로 RequestDelegate 는 자동 으로 채 워 집 니 다.신경 쓰 지 마 세 요.
중간 부품 은 Startup.cs 의 Configure 방법 에 등 록 됩 니 다.Configure 방법 은 IApplicationBuilder 인 자 를 가지 고 있 습 니 다.이 인 자 는 모든 종류의 미들웨어 등록 에 필요 한 방법 을 제공 합 니 다.미들웨어 를 만 들 려 고 합 니 다.

public class MyCustomMiddleware
 {
  private readonly RequestDelegate _next;
  public MyCustomMiddleware(RequestDelegate next)
  {
   _next = next;
  }
  public async Task Invoke(HttpContext context, IWebHostEnvironment env)
  {
   context.Response.Headers["app-name"] = env.ApplicationName+"Zaranet";
   context.Response.Headers["env-name"] = env.EnvironmentName+ "Zaranet";
   await _next(context);
  }
 }

그 다음 에 저 희 는 Startup.cs 의 Configure 방법 에서 use 를 통 해 사용자 정의 미들웨어 를 등록 합 니 다.

public void Configure(IApplicationBuilder app, ...)
{
 app.UseMyCustomMiddleware();
}

프로그램 을 시작 하면 우 리 는 정상 적 인 것 을 발견 하고 우리 가 원 하 는 효 과 를 얻 었 다.
 
그러나 실제 적 으로 UseMiddleware 를 직접 호출 할 필요 가 없습니다.미들웨어 작성 자의 표준 방법 은 등 록 된 미들웨어 에 특 정 된 확장 방법 을 만 드 는 것 이기 때 문 입 니 다.

using MiddlerWareSolucation.MiddlerWare;
using Microsoft.AspNetCore.Builder;

namespace MiddlerWareSolucation.MiddlerWare_Extensions
{
 public static class MyCustomMiddlewareExtensions
 {
  public static IApplicationBuilder UseMyCustomMiddleware(this IApplicationBuilder app)
  {
   app.UseMiddleware<MyCustomMiddleware>();

   return app;
  }
 }
}

그 다음 에 Extensions 확장 방법 을 직접 호출 하면 효 과 는 똑 같 습 니 다.

public void Configure(IApplicationBuilder app, ...)
{
 app.UseMyCustomMiddleware();
}

일부 때 저 희 는 클 라 이언 트 가 요청 한 경 로 를 통 해 미들웨어 를 시작 하려 고 합 니 다.물론 MapWhen 은 지정 한 서술 어 를 통 해 미들웨어 파 이 프 를 두 개의 완전히 독립 된 분기 로 나 눌 수 있 습 니 다.

app.UseMiddlewareOne();

app.MapWhen(context => context.Request.Path.StartsWithSegments("/api"), appBuilder =>
{
  appBuilder.UseMiddlewareTwo();
});

app.UseMiddlewareThree();

이 예제 에서 미들웨어 One 은 항상 실 행 됩 니 다.요청 경로 가'/api'로 시작 하면 미들웨어 Two 를 실행 합 니 다.그렇지 않 으 면 중간 부품 Three 를 실행 합 니 다.이 설정 을 사용 하면 미들웨어 2 와 미들웨어 3 는 하나의 요청 에 대해 실행 할 수 없습니다.
제 가 말씀 드 리 고 싶 은 것 은 마지막 상황 입 니 다.대부분의 미들웨어 가 모든 요청 에 대해 실행 되 기 를 원 하지만 일부 조건 이 있 습 니 다.-특정 미들웨어 는 특정한 요청 에 만 실행 되 어야 합 니 다.
UseWhen 을 통 해 쉽게 이 루어 집 니 다.UseWhen 은 술어 로 미들웨어 가 실행 되 어야 하 는 지 확인 할 수 있 습 니 다.

app.UseWhen(context => context.Request.Path.StartsWithSegments("/api"), appBuilder =>
{
 appBuilder.UseStatusCodePagesWithReExecute("/apierror/{0}");

 appBuilder.UseExceptionHandler("/apierror/500");
});

이렇게 하면 등록 방식 을 선택 하여 중간 부품 을 스스로 제어 할 수 있다.
이상 이 바로 본 고의 모든 내용 입 니 다.여러분 의 학습 에 도움 이 되 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다.