ASP.NET Core 란?
ASP.NET Core는 Microsoft가 개발한 웹 애플리케이션 프레임워크이다.
ASP.NET Core는 공개 소스로 릴리스되어 있으며, Windows, Linux 및 macOS와 같은 여러 플랫폼에서 실행될 수 있다.
1. Cross-platform support :
ASP.NET Core는 Windows, Linux 및 macOS와 같은 여러 플랫폼에서 실행될 수 있다.
개발자는 이러한 플랫폼 중 어느 것이든 선택할 수 있다.
2. High performance :
ASP.NET Core는 비동기 처리와 같은 기술을 사용하여 높은 처리량 및 성능을 제공한다.
이러한 기술은 애플리케이션의 응답 시간을 단축하고 처리량을 높이는 데 도움이 된다.
3. Modular architecture :
ASP.NET Core는 모듈식 아키텍처를 사용하여 개발자가 필요한 기능만 선택하여 사용할 수 있도록 한다.
이러한 모듈은 NuGet 패키지를 통해 제공되며, 개발자는 필요한 모듈만 설치하면 돤다.
4. Dependency injection :
ASP.NET Core는 의존성 주입(Dependency Injection)을 지원하여 개발자가 더 나은 코드를 작성할 수 있도록 한다.
이러한 기능은 코드의 유지 보수성과 테스트 용이성을 향상시키는 데 도움이 된다.
5. Web API support :
ASP.NET Core는 RESTful Web API를 개발하는 데 필요한 다양한 기능을 제공한다.
이러한 기능은 JSON 및 XML과 같은 다양한 형식으로 데이터를 반환하고,
인증 및 권한 부여와 같은 보안 기능을 제공하는 데 도움이 된다.
6. Razor Pages :
ASP.NET Core는 Razor Pages를 지원한다.
Razor Pages는 서버 측에서 렌더링되는 웹 페이지를 만들기 위한 간단한 구문을 제공한다.
7. SignalR :
ASP.NET Core는 SignalR을 지원한다.
SignalR은 웹 소켓과 같은 실시간 웹 기술을 사용하여 서버와 클라이언트 간에 양방향 통신을 제공한다.
이러한 기능은 ASP.NET Core가 다양한 애플리케이션을 개발하는데 사용 될수 있도록 한다.
ASP.NET Core는 간단한 웹 사이트부터 복잡한 엔터프라이즈 애플리케이션 까지 개발하는데 사용 될 수 있다
ASP.NET Core 7 기본 사항 개요 :
* 위 링크는 DI(종속성 주입), 구성, 미들웨어 등을 포함하여 ASP.NET Core 앱을 빌드하기 위한 기본 사항의 개요를 간략한 설명
Program.cs
- Program.cs는 애플리케이션의 진입점이다.
- 앱에서 요구하는 서비스가 구성된다.
- 앱의 요청 처리 파이프라인이 인련의 미들웨어 구성 요소로 정의된다.
ASP.NET Core 의 구성
ASP.NET Core 미들웨어
미들웨어는 요청 및 응답을 처리하는 앱 파이프라인으로 조립되는 소프트웨어 컴포넌트이다.
미들웨어는 요청을 처리하기 전에, 후에 또는 요청-응답 사이에서 실행 될 수 있다.
ASP.NET Core에서는 미들웨어를 사용하여 요청 처리를 확장하고 사용자 지정 요구 사항을 쉽게 처리 할 수 있다.
ASP.NET Core의 미들웨어는 IApplicationBuilder 인터페이스를 사용하여 미들웨어 파이프라인을 만든다.
미들웨어 파이프라인은 요청 처리를 확장하는데 사용된다.
파이프라인은 하나씩 차례로 호출되는 요청 대리자 시퀀스로 구성된다.
각 대리자는 다음 대리자 전과 후에 작업을 수행할 수 있다.
예외 처리 대리자는 파이프라인의 이후 단계에서 발생하는 예외를 잡을 수 있도록 파이프라인의 초기에 호출되어야 한다.
ASP.NET Core에서는 정적 파일을 처리하기 위한 미들웨어도 제공한다.
ASP.NET Core에서 종속성 주입(Dependency Injection)
ASP.NET Core는 클래스와 해당 종속성 간의 IOC(Inversion of Control)를 실현하는 기술인
DI(종속성 주입) 소프트웨어 디자인 패턴을 지원한다.
ASP.NET Core에서는 종속성 주입을 위해 IServiceCollection 인터페이스를 사용한다.
이 인터페이스를 사용하여 서비스를 등록하고, 필요한 곳에서 해당 서비스를 사용할 수 있다.
ASP.NET Core에서는 서비스를 등록할 때, 서비스의 수명 범위를 지정할 수 있다.
서비스의 수명 범위는 주로 Singleton, Scoped, Transient 세 가지로 나뉜다.
- Singleton: 앱 전체에서 단일 인스턴스를 사용한다. 이는 앱에서 단일 인스턴스를 공유해야 하는 경우에 유용하다.
- Scoped: HTTP 요청 범위 내에서 단일 인스턴스를 사용한다. 이는 HTTP 요청 처리를 위해 일시적으로 생성된 서비스를 다룰 때 유용하다.
- Transient: 서비스가 요청될 때마다 새 인스턴스를 생성합니다. 이는 새로운 인스턴스가 필요한 경우 사용된다.
ASP.NET Core 단점
1. Learning curve :
ASP.NET Core는 다른 웹 프레임워크와 달리 새로운 개념과 구성 요소를 도입하기 때문에 학습 곡선이 다소 높을 수 있다.
2. Limited third-party library support :
ASP.NET Core가 비교적 새로운 프레임워크이기 때문에
이전 버전의 ASP.NET과 비교하여 아직 많은 라이브러리와 플러그인이 지원되지 않을 수 있다.
3. Lack of backward compatibility :
ASP.NET Core는 이전 버전의 ASP.NET과 호환되지 않기 때문에 기존 ASP.NET 애플리케이션을 업그레이드하는 데 시간과 비용이 많이 들 수 있다.
4. Debugging can be difficult :
ASP.NET Core는 이전 버전의 ASP.NET과 비교하여 디버깅이 어렵다.
이는 코드의 모듈성과 개발 환경의 도구와 함께 고려해야 하는 요인이다.
5. Limited community support :
ASP.NET Core의 커뮤니티는 아직 비교적 작은 편이기 때문에 도움이 필요한 경우 지원을 찾기가 어려울 수 있다.
ASP.NET Core 7
- ConfigureServices메서드 : 사용하여 앱에서 요구하는 서비스를 구성하고,
이 메서드에서는 서비스를 응용 프로그램의 서비스 컨테이너에 등록하는 코드를 작성한다.
ASP.NET Core에서 서비스는 DI(Dependency Injection) 컨테이너를 통해 등록되고 관리된다.
- Configure 메서드 : HTTP 요청 파이프라인을 구성한다.
이 메서드에서는 응용 프로그램의 요청 처리 미들웨어를 구성한다.
리턴 타입이 'void'가 아니라 'IApplicationBuilder' 로 변경 되었다.
이는 미들웨어를 추가하고 미들웨어를 구성하는 방법이 변경 되었음을 의미한다.
또한, 애플리케이션의 라우팅, 예외처리, 스택틱 파일 서비스 등의 기능을 구성할 수 있다.
ASP.NET Core 7에서는 더욱 강력한 기능과 유연한 구성을 위해 미들웨어 구성 방법이 변경되었다.
Configure메서드 내부에서 Use 메서드를 호출하는 방식으로 구성한다.
이렇게 구성한 미들웨어는 순서대로 연결되어 요청 파이프라인을 구성한다.
또한, 필요에 따라 미들웨어 간에 파라미터를 전달하여 조합할 수 있다.
ASP.NET Core 런타임에 의해 호출되며,
'WebHostBuilder'가 'WebApplicationBuilder' 로 변경되었다.
'WebHostBuilder'는 ASP.NET Core 6에서 사용되는 기존의 호스팅 모델이었지만,
'WebApplicationBuilder'는 앱의 환경에 더 적합하도록 설계된 새로운 모델이다.
WebApplicationBuilder는 또한 Configure* 메서드를 통해 초기 설정을 구성하는 설정 제공자를 제공한다.
따라서, ASP.NET Core 7의 Startup.cs 파일은 조금 더 최신의 기술과 함께 변경되었다.
이전 버전과는 약간 다른 방식으로 서비스를 구성하고 미들웨어를 추가할 수 있다.
Microsoft.AspNetCore.Builder 네임스페이스 :
애플리케이션에 기본 제공 미들웨어를 추가하는 메서드와 미들웨어에 대한 옵션 유형이다.
Microsoft.AspNetCore.Builder 클래스는 ASP.NET Core 애플리케이션의 요청 처리, 파으프라인을 구성하는데 사용 된다.
ASP.NET Core 응용 프로그램의 시작 부분에서 사용되어,
응용 프로그램에 미들웨어를 추가하고 구성하는 데 필요한 메서드를 제공한다.
ASP.NET Core 7에서는 Microsoft.AspNetCore.Builder 클래스는 애플리케이션의
요청 처리 파이프라인을 구성하는데 사용되는 일련의 확장 메서드를 제공한다.
확장 메서드를 사용하여 애플리케이션에 미들웨어를 추가하고, 미들웨어에 필요한 구성 옵션을 지정하고,
미들웨어의 실행 순서를 조정할 수 있다.
WebApplication.CreateBuilder() :
미리 구성된 기본값을 사용하여 클래스의 WebApplicationBuilder 새 인스턴스를 초기화한다.
WebApplication.CreateBuilder(WebApplicationOptions) : 미리 구성된 기본값을 사용하여 클래스의 새 인스턴스를 초기화
WebApplication.CreateBuilder(String[]) : 미리 구성된 기본 값을 사용하여 클래스의 새 인스턴스를 초기
WebApplication.CreateBuilder(args)는 'WebApplicationBuilder' 클래스의 새 인스턴스를 초기화
이 'WebApplicationBuilder' 객체는 앱의 구성을 빌드하기 위한 기본값을 설정한다.
WebApplicationBuilder'는 설정 제공자 (Configure* 메서드)를 호출하여 초기 설정을 구성한다.
이러한 설정 제공자는 우선순위에 따라 순서대로 호출된.
기본적으로 제공되는 제공자:
ConfigureHostConfiguration() :
호스트 구성을 구성하기 위한 메서드 체인의 첫번째 메서드이다 ??
메서드는 호스트 구성을 위한 구성 빌더 메서드 중 하나이다.
이 메서드는 호스트 구성을 구성하기 위해 사용됩니다.
ASP.NET Core 애플리케이션은 호스트와 애플리케이션 두 가지 기본 구성 요소로 구성된다.
호스트 구성은 애플리케이션을 실행하는 데 필요한 런타임, 서버, 인증 설정, 로깅 등과 같은 서비스를 구성한다.
반면, 애플리케이션 구성은 애플리케이션에서 사용하는 데이터베이스, 서비스, 인증, 로깅 등과 같은 애플리케이션 관련 설정을 구성한다.
ConfigureHostConfiguration() 메서드는 호스트 구성을 위한 IConfigurationBuilder 인스턴스를 제공한다.
이 메서드는 다양한 구성 소스에서 호스트 구성을 로드하는 데 사용된다.
이 메서드는 일반적으로 환경 변수, 명령줄 인수, JSON 파일 등과 같은 구성 소스에서 호스트 구성을 로드한다.
ConfigureHostConfiguration(IConfigurationBuilder) :
호스트 환경을 구성하는데 사용된다.
이 메서드는 IConfigurationBuilder객체를 인자로 받아, 호스트의 구성 정보를 빌드한다.
ConfigureLogging(ILoggingBuilder) :
ASP.NET Core 7의 ConfigureLogging() 메서드는 로깅을 구성하기 위한 메서드이다.
이 메서드는 IHostBuilder 인터페이스를 사용하여 호스트 빌더를 구성하는 ConfigureHostConfiguration() 및 ConfigureAppConfiguration() 메서드 호출 후에 호출된다.
ConfigureLogging() 메서드를 사용하여 로그 출력을 구성하고 로그 레벨을 설정할 수 있다.
이 메서드는 ILoggingBuilder 인터페이스를 반환하며,
이를 사용하여 다양한 로그 공급자 (provider)를 구성할 수 있다.
ASP.NET Core 7에서는 기본적으로 콘솔 로그 공급자가 제공된다.
따라서 애플리케이션의 로그를 콘솔에 출력하려면 ConfigureLogging() 메서드를 구현할 필요가 없다.
그러나 파일 또는 데이터베이스 같은 다른 로그 공급자를 사용하려는 경우
ConfigureLogging() 메서드를 사용하여 해당 공급자를 구성해야 한다.
ConfigureServices(IServiceCollection) :
애플리케이션에서 사용될 서비스를 등록하는 메서드이다.
이 메서드는 개발자가 직접 호출할 필요 없이, 실행 시 ASP.NET Core 런타임이 자동으로 호출한다.
이 메서드 내에서 등록한 서비스는 애플리케이션 전반에서 사용될 수 있다.
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
Configuration.GetConnectionString("DefaultConnection")));
services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<ApplicationDbContext>();
services.AddRazorPages();위 예제에서는 AddDbContext, AddDefaultIdentity, AddRazorPages 등의 확장 메서드를 사용하여 서비스를 등록한다.
이러한 확장 메서드는 ASP.NET Core에서 제공하는 프레임워크에서 제공하는 서비스를 등록할 수 있다.
서비스 컨테이너에 등록되는 서버시는 다음과 같이 세가지 범주로 구분 할 수 있다.
- 프레임워크에서 제공하는 서비스
- 서비스 컨테이너에서 만들지 않은 서비스
- 사용자가 만든 서비스
설정 제공자(Configuration Provider)
ASP.NET Core 7에서는 다양한 방법으로 설정 정보를 제공할 수 있도록 설정 제공자(Configuration Provider)를 제공한다.
설정 제공자는 IConfigurationProvider 인터페이스를 구현하여
설정 정보를 가져오고 이를 IConfiguration 인터페이스로 캡슐화한다.
ASP.NET Core 7에서 기본으로 제공하는 설정 제공자 목록 :
- 명령줄 인수(ConfigurationCommandLineParser) - dotnet run 명령으로 실행할 때 전달된 인수를 읽어온다.
- 환경 변수(ConfigurationEnvironmentVariables) - OS의 환경 변수를 읽어온다.
- JSON 파일(ConfigurationJsonFile) - appsettings.json 및 appsettings.{Environment}.json 파일을 읽어온다.
- XML 파일(ConfigurationXmlFile) - app.config 또는 web.config 파일에서 설정을 읽어온다.
- INI 파일(ConfigurationIniFile) - INI 파일에서 설정을 읽어온다.
- 키 및 값(ConfigurationKeyValuePair) - 코드 내부에서 설정 정보를 직접 지정한다.
사용자 정의 설정 제공자를 구현하여 다른 소스에서 설정 정보를 가져올 수도 있다.
사용자 정의 설정 제공자는 IConfigurationProvider를 구현하고,
ConfigureServices() 메서드에서 AddConfiguration() 메서드를 사용하여 등록할 수 있다.
Appsettings.json
이 제공자는 appsettings.json 파일에 정의된 설정값들을 앱에 제공하며 프로젝트 빌드 후에 출력 폴더에 함께 복사된다.
주로 ConfigureServices() 메서드에서 읽어와서 사용한다.
Appsettings.development.json 구성은 appsetting.json에 있는 값을 제정의 하는 기능을 한다.
프로젝트가 빌드 후에, 출력 폴더에 함께 복사된 후 출력폴더의 다른 파일들과 함께 실행할 시스템에 옮겨지고,
dotnet run의 입력을 통해 웹앱이 실행될 때, 코드 내의 설정값들이 appsettings.json 파일에 의해 결정되는 것이다.
Json문서의 일반적인 구조를 따르지만 설정의 section과 적용될 값의 쌍으로 정의한다.
ConfigureAppConfiguration() :
ASP.NET Core 7에서 'ConfigureAppConfiguration()' 메서드는 애플리케이션의 구성 설정을 구성하는데 사용된다.
'ConfigureAppConfiguration()' 메서드는 'WebHostBuilder' 또는
'WebApplicationFactory' 와 같은 호스팅 API를 사용하여 애플리케이션을 구성하는 중요한 부분이다.
이 메서드는 'IConfigurationBuilder'를 구성하는데 사용되며,
애플리케이션 구성에 대한 다양한 공급자를 구성할 수 있다.
애플리케이션 구성을 JSON 파일에서 로드하고, 환경 변수에서 값을 가져오고,
명령행 매개변수에서 값을 가져오도록 구성할 수 있다.
다음은 'ConfiguraAppConfiguration()' 메서드를 사용하여 JSON 파일에서 애플리케이션 구성을 로드하는 예제:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
config.SetBasePath(Directory.GetCurrentDirectory());
config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
위의 예제에서 config.SetBasePath()를 사용하여 애플리케이션 구성 파일이 있는 디렉토리를 설정하고,
config.AddJsonFile()을 사용하여 JSON 파일을 구성에 추가한다.
optional 매개변수가 false로 설정되어 있으므로 파일이 없으면 예외가 발생합니다.
reloadOnChange 매개변수가 true로 설정되어 있으므로 파일이 변경될 때마다 구성이 자동으로 다시 로드된다.
SetBasePath :
1. 설정파일 등을 검색할 기본 위치를 설정한다.
2. 설정은 안 하면 실행 파일이 존재하는 위치에 설정한다.
3. 웹 서비스를 실행하는 서비스(클라우드 앱 서비스나 Azure Fucntions 등) 에서는 실행되는 위치를 Directory.GetCurrentDirectory()를 설정해 두어야 서비스가 실행되는 위치를 기점으로 파일을 검색한다.
4. 모든 설정파일을 한 폴더에 위치할 필요는 없고 용도에 때라 기본 경로만 설정하고 나머지는 '폴더명\파일명' 식으로 찾도록 할 수 있다.
AddJsonFile :
1. JSON 파일을 읽어서 속성 값을 등록한다.
2. 사용시에는 SetBasePath 에서 설정하거나 설정하지 않았다면 실행 파일 위치를 기주능로 경로를 입력한 파일을 찾는다.
3. optional을 false로 설정시 반드시 파일이 존재해야만 한다.
4. optional을 true로 설정시 파일이 존재하지 않으면 속성을 추가하지 않는다.
5. 나중에 호출한 메서드로 속성 값이 덮어 씌어지게 된다. 만약 'local.settings.json'과 'local.{envSetting}.json'파일에서 같은 Key값 ' Test'가 존재한다고 하면 나중에 호출한 'local.{envSetting}.json'에서 설정한 값으로 속성 값이 정해진다.
6. Git이나 앱 서비스 상에 업로드 시에는 Optional 값을 true로 한 파일을 환경변수나 Secret으로 해당 경로에 생성한 파일을 사용한다.
7. reloadOnChange 변수는 reload 이벤트 핸들러 실행 시 (파일이 변경) 변경 사항을 다시 불러올지 여부를 뜻한다.
WebApplicationBuilder 클래스 :
ASP.NET Core 7에서도 'WebApplicationBuilder' 클래스는 유지된다.
이 클래스는 애플리케이션의 구성을 설정하고, 서비스를 등록하고, 애플리케이션을 실행하는데 사용된다.
'WebApplicationBuilder' 클래스는 'IHostBuilder' 인터페이스를 상속하므로,
.NET Generic Host 기반의 애플리케이션에서 사용된다.
'WebApplication' 클래스는 'IHost'인터페이스를 상속하므로,
'WebApplicationBuilder' 클래스의 인스턴스를 실행하면 'IHost' 인터페이스의 메서드를 사용할 수 있다.
To create a new web application using the
(WebApplicationBuilder), you can use the following code :
위 코드는 ASP.NET Core 7에서 WebApplication을 생성하는 방법을 보여주는 예제이다.
WebApplication을 생성하기 위해서 WebApplicationBuilder를 먼저 생성한 후,
Build()메소드를 호출하여 WebApplication 인스턴스를 만듭니다.
WebApplicationBuilder를 사용하는 것은 웹 애플리케이션을 구성하는 더 간단하고 직관적인 방법을 제공한다.
특히, ASP.NET Core 7에서 새롭게 도입된 Minimal API를 더 잘 지원하도록 설계되었다.
하지만, WebApplicationBuilder를 사용하는 것에는 일부 단점도 있다.
예를 들어, 더 세부적인 설정을 제어하는 데에는 WebHostBuilder 및 HostBuilder API와 같이 더 유연한 방법이 있다.
또한, 예전 API를 사용하던 개발자들은 WebApplicationBuilder 를 사용하는데 적용하는 데 시간이 걸릴 수도 있다.
총괄적으로, WebApplicationBuilder는 ASP.NET Core 7 에서 웹 애플리케이션을 구성하고 빌드하는 더
단순하고 간편한 방법을 제공한다.
기본적으로 WebApplicationBuilder는 Kestrel 웹 서버를 사용하고, ISS통합을 사용하지 않도록 구성된다.
또한 구성 파일은 appsettings.json, 환경 변수, 명령줄 인수 등에서 로드된다.
로깅 출력은 콘솔, 파일 또는 이벤트 로그와 같은 로깅 공급자에게 전달된다.
services.AddControllers()
는ASP.NET Core 애플리케이션에서 컨트롤러 기능을 사용하기 위해 의존성 컨테이너 컨트롤러를 등록하는 메서드이다.
이 메서드를 호출하면, ASP.NET Core애플리케이션의 서비스 컬렉셜
('IServiceCollection')에 'Controller' 클래스와 파생클래스의 객체들이 등록된다.
이러한 객체들은 각각의 HTTP요청에 대해 응답을 생성하기 위한 작업을 처리하는데 사용된다.
이 메서드를 호출하는 것은 컨트롤러에 대한 의존성을 주입하기 위한 필수 단계 중 하나이다.
이전 버전의 ASP.NET과 달리, ASP.NET Core에서는 '
AddControllers()'를 호출하지 않으면 애플리케이션에서 인식되지 않기 때문이다.
또한 'services.AddControllers()'메서드를 통해 컨트롤러의 기본 구성 요소들도 함께 등록되므로, 편리하다.
- Web API 관련 모듈을 사용 선언이다.
ASP.NET Core에서 라우팅
라우팅은 들엉는 HTTP요청을 일치시켜 앱의 실행 가능 엔드포인트로 디스패치하는 역할을 담당한다.
엔드포인트는 앱의 실행 가능 요청 처리 코드 단위이다.
엔드포인트는 앱에서 정의되고 앱 시작 시 구성된다.
엔드포인트 일치 프로세스는 요청의 URL에서 값을 추출하고 처리를 위해 이 값을 제공할 수 있다.
또한 라우팅은 앱의 엔드포인트 정보를 사요앟여 엔드포인트에 매핑되는 URL을 생성할 수도 있다.
라우팅은 URL 경로를 애플리케이션의 동작 또는 작업에 매핑하는 프로세스이다.
라우팅은 요청 URL을 분석하여 애플리케이션의 적절한 핸들러(컨트롤러 액션)를 호출하는데 사용된다.
ASP.NET Core 7 에서는 라우팅을 구성하기 위해 다음과 같은 방법이 제공된다.
1. 라우팅 미들웨어 :
ASP.NET Core 7에서는 라우팅을 위해 미들웨어를 사용한다.
이를 위해 UseRouting() 메서드를 사용하여 라우팅 미들웨어를 등록한다.
이후 UseEndpoints() 메서드를 사용하여 핸들러를 등록한다.
이 핸들러는 HTTP 요청에 대한 응답을 생성하는 액션 메서드를 의미한다.
UseRouting() : 경로 일치를 미들웨어 파으프라인에 추가한다.
이 미들웨어는 앱의 정의된 엔드포인트 집합을 확인하고 요청을 기반으로 가장 일치하는 항목을 선택한다.
UseEndpoints() : 엔드포인트 실행을 미들웨어 파이프라인에 추가한다.
선택한 엔드포인트와 연결된 대리자를 실행한다.
MapGet() : 엔드포인트를 정의하는데 사용된다.
엔드포인트는 -URL 및 HTTP메서드를 일치시키는데 선택된다.
대리자를 실행하여 실행된다.
앱에서 일치시키고 실행할 수 있는 엔드포인트는 UseEndpoints에서 구성된다.
예를 들어 MapGet, MapPost 및 이들과 유사한 메서드는 요청 대리자를 라우팅 시스템에 연결한다.
ASP.NET Core Framework 기능을 라우팅 시스템에 연결하는 데 다음과 같은 추가 메서드를 사용할 수 있다.
앱은 일반적으로 UseRouting 또는 UseEndpoints를 호출할 필요가 없다.
WebApplicationBuilder는 UseRouting 및 UseEndpoints를 통해
Program.cs에 추가된 미들웨어를 래핑하는 미들웨어 파이프라인을 구성한다.
그러나 앱은 이러한 메서드를 명시적으로 호출하여 UseRouting 및 UseEndpoints 실행 순서를 변경할 수 있다.
2. 액션 메서드 라우팅 :
액션 메서드 라우팅은 액션 메서드의 이름과 HTTP 동사(예 : GET, POST 등)를 기반으로 라우팅을 수행한다.
이 방법은 복잡한 라우팅이 필요하지 않을 때 유용한다.
3. 지역화 라우팅 :
ASP.NET Core 7에서는 지역화 라우팅ㅇ을 사용하여 지역화된 액션 메서드를 라우팅 한다.
이를 위해 IRouteBuilder인터페이스를 사용하여 다국어 URL을 구성할 수 있다.
4. 속성 기반 라우팅 :
속성 기반 라우팅은 HTTP 요청의 속성 값을 기반으로 라우팅을 수행한다.
이 방법은 보안 및 인증 요구 사항을 충족시키기 위해 사용된다.
이러한 방법을 조합하여 ASP.NET Core 7에서 다양한 유형의 라우팅을 구성할 수 있다.
ASP.NET Core 7에서 지원되는 2 가지 유형 라우팅
1. Convention-based routing : 컨트롤러 및 액션 메서드의 이름과 일치하는 URL 경로를 생성한다.
2. Attribute routing : 액션 메서드에 대한 특성을 사용하여 경로를 정의한다.
이는 보다 명시적이고 유연한 방식이며, 특정 액션 메서드를 선택하여 경로를 정의 할 수 있다.
ASP.NET Core 버전별 설명
ASP.NET Core는 1.x, 2.x, 3.x, 5.x 버전으로 나뉜다.
1. ASP.NET Core 1.x :
2016년에 출시, 크로스 플랫폼 및 클라우드 네이티브 애플리케이션 개발을 위해 설계되었다.
이 버전은 새로운 프레임워크로서 많은 개선 사항을 가져왔지만, 몇 가지 누락된 기능 및 라이브러리가 있었다.
2. ASP.NET Core 2.x :
2017년에 출시, ASP.NET Core 1.x의 성능과 안정성을 개선하였다.
이 버전에서는 Razor Pages 및 SignalR과 같은 새로운 기능과 개선된 속도 및 메모리 사용량 감소가 추가되었다.
3. ASP.NET Core 3.x :
2019년에 출시, C# 8 및 .NET Core 3.0과 함께 출시되었다.
이 버전에서는 개선된 성능, 개선된 API 지원, SignalR 지원 및 보안 기능이 추가되었다.
4. ASP.NET Core 5.x :
2020년에 출시되었으며, 이전 버전과 비교하여 성능과 안정성을 개선했다.
이 버전에서는 개선된 API 지원, 새로운 JSON 라이브러리, 개선된 Razor 구문 분석, C# 9 및 개선된 gRPC 지원이 추가되었다.
또한 .NET 5.0의 출시와 함께 ASP.NET Core 5.0은 .NET 5.0을 대상으로 하는 첫 번째 버전이다.
5. ASP.NET Core 6.x :
2021년에 출시되었다.
*위 내용 오타 및 수정 해야 하는 내용 있으면 댓글로 알려주시면 감사합니다.