ASP.NET Core MVC에서 컨트롤러를 사용한 요청 처리Handle requests with controllers in ASP.NET Core MVC

작성자: Steve SmithScott AddieBy Steve Smith and Scott Addie

컨트롤러, 작업 및 작업 결과는 개발자가 ASP.NET Core MVC를 사용하여 앱을 구축하는 방법에서 기본적인 부분입니다.Controllers, actions, and action results are a fundamental part of how developers build apps using ASP.NET Core MVC.

컨트롤러란?What is a Controller?

컨트롤러는 일련의 작업을 정의하고 그룹화하는 데 사용됩니다.A controller is used to define and group a set of actions. 작업(또는 작업 메서드)은 요청을 처리하는 컨트롤러의 메서드입니다.An action (or action method) is a method on a controller which handles requests. 컨트롤러는 논리적으로 유사한 작업을 함께 그룹화합니다.Controllers logically group similar actions together. 이 작업 집계를 통해 라우팅, 캐싱 및 권한 부여와 같은 일반적인 규칙 집합을 전체적으로 적용할 수 있습니다.This aggregation of actions allows common sets of rules, such as routing, caching, and authorization, to be applied collectively. 요청은 라우팅을 통해 작업에 매핑됩니다.Requests are mapped to actions through routing.

규칙에 따른 컨트롤러 클래스:By convention, controller classes:

  • 프로젝트의 루트 수준 Controllers 폴더에 있음Reside in the project's root-level Controllers folder
  • Microsoft.AspNetCore.Mvc.Controller에서 상속Inherit from Microsoft.AspNetCore.Mvc.Controller

컨트롤러는 다음 조건 중 하나 이상이 true인 인스턴스화할 수 있는 클래스입니다.A controller is an instantiable class in which at least one of the following conditions is true:

  • 클래스 이름에 접미사 “Controller”가 붙음The class name is suffixed with "Controller"
  • 클래스가 이름에 접미사 “Controller”가 붙는 클래스에서 상속The class inherits from a class whose name is suffixed with "Controller"
  • 클래스가 [Controller] 특성으로 데코레이트됨The class is decorated with the [Controller] attribute

컨트롤러 클래스에는 연결된 [NonController] 특성이 있어야 합니다.A controller class must not have an associated [NonController] attribute.

컨트롤러는 명시적 종속성 원칙을 따라야 합니다.Controllers should follow the Explicit Dependencies Principle. 이 원칙을 구현하는 방법에는 몇 가지가 있습니다.There are a couple of approaches to implementing this principle. 여러 컨트롤러 작업에서 동일한 서비스가 필요한 경우 해당 종속성을 요청하는 데 생성자 주입을 사용하는 것을 고려합니다.If multiple controller actions require the same service, consider using constructor injection to request those dependencies. 서비스가 단일 작업 메서드에 필요한 경우에는 종속성을 요청하는 데 작업 주입을 사용하는 것을 고려합니다.If the service is needed by only a single action method, consider using Action Injection to request the dependency.

Model-View-Controller(모델 뷰 컨트롤러) 패턴 내에서 컨트롤러는 초기 요청 처리 및 모델의 인스턴스화를 담당합니다.Within the Model-View-Controller pattern, a controller is responsible for the initial processing of the request and instantiation of the model. 일반적으로 비즈니스 의사 결정은 모델 내에서 수행되어야 합니다.Generally, business decisions should be performed within the model.

컨트롤러는 모델의 처리 결과(있는 경우)를 사용하고, 적절한 보기와 관련된 보기 데이터 또는 API 호출의 결과를 반환합니다.The controller takes the result of the model's processing (if any) and returns either the proper view and its associated view data or the result of the API call. ASP.NET Core MVC 개요ASP.NET Core MVC 및 Visual Studio 시작에서 자세히 알아봅니다.Learn more at Overview of ASP.NET Core MVC and Get started with ASP.NET Core MVC and Visual Studio.

컨트롤러는 UI 수준 추상화입니다.The controller is a UI-level abstraction. 해당 업무는 요청 데이터가 올바른지 확인하고 어떤 보기(또는 API에 대한 결과)를 반환해야 하는지 선택하는 것입니다.Its responsibilities are to ensure request data is valid and to choose which view (or result for an API) should be returned. 잘 구성된 앱에서는 데이터 액세스 또는 비즈니스 논리를 직접 포함하지 않습니다.In well-factored apps, it doesn't directly include data access or business logic. 대신, 컨트롤러는 이러한 책임을 처리하는 서비스에 위임합니다.Instead, the controller delegates to services handling these responsibilities.

작업 정의하기Defining Actions

컨트롤러의 공용 메서드는 [NonAction] 특성으로 데코레이트된 경우 이외에는, 작업입니다.Public methods on a controller, except those decorated with the [NonAction] attribute, are actions. 작업에서의 매개 변수는 요청 데이터에 바인딩되며 모델 바인딩을 사용하여 유효성 검사가 수행됩니다.Parameters on actions are bound to request data and are validated using model binding. 모델 유효성 검사는 모델 바인딩되는 모든 작업에 대해 발생합니다.Model validation occurs for everything that's model-bound. ModelState.IsValid 속성 값은 모델 바인딩 및 유효성 검사의 성공 여부를 나타냅니다.The ModelState.IsValid property value indicates whether model binding and validation succeeded.

작업 메서드는 비즈니스 문제에 요청을 매핑하는 것에 대한 논리를 포함해야 합니다.Action methods should contain logic for mapping a request to a business concern. 비즈니스 문제는 일반적으로 컨트롤러가 종속성 주입을 통해 액세스하는 서비스로 표시되어야 합니다.Business concerns should typically be represented as services that the controller accesses through dependency injection. 그런 다음 작업은 비즈니스 작업의 결과를 응용 프로그램 상태에 매핑합니다.Actions then map the result of the business action to an application state.

작업은 모든 항목을 반환할 수 있지만, 응답을 생성하는 IActionResult(또는 비동기 메서드에 대한 Task<IActionResult>)의 인스턴스를 자주 반환합니다.Actions can return anything, but frequently return an instance of IActionResult (or Task<IActionResult> for async methods) that produces a response. 작업 메서드는 응답의 종류를 선택합니다.The action method is responsible for choosing what kind of response. 작업 결과는 응답을 수행합니다.The action result does the responding.

컨트롤러 도우미 메서드Controller Helper Methods

컨트롤러는 일반적으로 Controller에서 상속합니다. 단, 이는 필수가 아닙니다.Controllers usually inherit from Controller, although this isn't required. Controller에서의 파생은 도우미 메서드의 세 범주에 대한 액세스를 제공합니다.Deriving from Controller provides access to three categories of helper methods:

1. 빈 응답 본문으로 이어지는 메서드1. Methods resulting in an empty response body

응답 본문에 설명할 콘텐츠가 없으므로 Content-Type HTTP 응답 헤더가 포함되지 않습니다.No Content-Type HTTP response header is included, since the response body lacks content to describe.

이 범주 내에는 리디렉션 및 HTTP 상태 코드의 두 가지 결과 형식이 있습니다.There are two result types within this category: Redirect and HTTP Status Code.

  • HTTP 상태 코드HTTP Status Code

    이 형식은 HTTP 상태 코드를 반환합니다.This type returns an HTTP status code. 이러한 형식의 몇 가지 도우미 메서드는 BadRequest, NotFoundOk입니다.A couple of helper methods of this type are BadRequest, NotFound, and Ok. 예를 들어 return BadRequest();는 실행될 때 400 상태 코드를 생성합니다.For example, return BadRequest(); produces a 400 status code when executed. BadRequest, NotFoundOk와 같은 메서드가 오버로드되는 경우 콘텐츠 협상이 수행되고 있으므로 더 이상 HTTP 상태 코드 응답자로의 자격이 없습니다.When methods such as BadRequest, NotFound, and Ok are overloaded, they no longer qualify as HTTP Status Code responders, since content negotiation is taking place.

  • 리디렉션Redirect

    이 형식은 작업 또는 대상에 리디렉션을 반환합니다(Redirect, LocalRedirect, RedirectToAction 또는 RedirectToRoute 사용).This type returns a redirect to an action or destination (using Redirect, LocalRedirect, RedirectToAction, or RedirectToRoute). 예를 들어 return RedirectToAction("Complete", new {id = 123});Complete로 리디렉션하여 익명 개체를 전달합니다.For example, return RedirectToAction("Complete", new {id = 123}); redirects to Complete, passing an anonymous object.

    리디렉션 결과 형식은 주로 Location HTTP 응답 헤더와 더불어 HTTP 상태 코드 형식에 따라 다릅니다.The Redirect result type differs from the HTTP Status Code type primarily in the addition of a Location HTTP response header.

2. 미리 정의된 콘텐츠 형식의 비어 있지 않은 응답 본문으로 이어지는 메서드2. Methods resulting in a non-empty response body with a predefined content type

이 범주의 도우미 메서드 대부분은 ContentType 속성을 포함하므로 응답 본문을 설명하도록 Content-Type 응답 헤더를 설정할 수 있습니다.Most helper methods in this category include a ContentType property, allowing you to set the Content-Type response header to describe the response body.

이 범주 내의 결과 형식은 보기서식 있는 응답의 두 가지가 있습니다.There are two result types within this category: View and Formatted Response.

  • 보기View

    이 형식은 HTML을 렌더링하는 모델을 사용하는 보기를 반환합니다.This type returns a view which uses a model to render HTML. 예를 들어 return View(customer);는 데이터 바인딩을 위한 보기에 모델을 전달합니다.For example, return View(customer); passes a model to the view for data-binding.

  • 서식 있는 응답Formatted Response

    이 형식은 JSON 또는 비슷한 데이터 교환 형식을 반환하여 개체를 지정된 방식으로 표시합니다.This type returns JSON or a similar data exchange format to represent an object in a specific manner. 예를 들어 return Json(customer);은 JSON 형식에 제공된 개체를 직렬화합니다.For example, return Json(customer); serializes the provided object into JSON format.

    이 형식의 다른 일반적인 방법에는 File, PhysicalFileVirtualFile이 포함됩니다.Other common methods of this type include File, PhysicalFile, and VirtualFile. 예를 들어 return PhysicalFile(customerFilePath, "text/xml");은 “text/xml”의 Content-Type 응답 헤더 값으로 설명되는 XML 파일을 반환합니다.For example, return PhysicalFile(customerFilePath, "text/xml"); returns an XML file described by a Content-Type response header value of "text/xml".

3. 클라이언트와 협상된 콘텐츠 형식으로 서식이 지정된 비어 있지 않은 응답 본문으로 이어지는 메서드3. Methods resulting in a non-empty response body formatted in a content type negotiated with the client

이 범주는 콘텐츠 협상으로 더 잘 알려져 있습니다.This category is better known as Content Negotiation. 콘텐츠 협상은 작업이 ObjectResult 형식 또는 IActionResult 구현 외 항목을 반환할 때마다 적용됩니다.Content negotiation applies whenever an action returns an ObjectResult type or something other than an IActionResult implementation. IActionResult 구현을 반환하는 작업(예: object)도 서식 있는 응답을 반환합니다.An action that returns a non-IActionResult implementation (for example, object) also returns a Formatted Response.

이 형식의 몇 가지 도우미 메서드에는 BadRequest, CreatedAtRouteOk가 포함됩니다.Some helper methods of this type include BadRequest, CreatedAtRoute, and Ok. 이러한 메서드의 예에는 각각 return BadRequest(modelState);, return CreatedAtRoute("routename", values, newobject);return Ok(value);가 있습니다.Examples of these methods include return BadRequest(modelState);, return CreatedAtRoute("routename", values, newobject);, and return Ok(value);, respectively. BadRequestOk는 값이 전달될 때만 콘텐츠 협상을 수행합니다. 값을 전달하지 않으면 대신 HTTP 상태 코드 결과 형식으로 제공합니다.Note that BadRequest and Ok perform content negotiation only when passed a value; without being passed a value, they instead serve as HTTP Status Code result types. 반면, CreatedAtRoute 메서드는 해당 오버로드에서는 모두 값이 전달되어야 하므로 항상 콘텐츠 협상을 수행합니다.The CreatedAtRoute method, on the other hand, always performs content negotiation since its overloads all require that a value be passed.

교차 편집 문제Cross-Cutting Concerns

응용 프로그램은 일반적으로 해당 워크플로의 일부를 공유합니다.Applications typically share parts of their workflow. 예를 들어 쇼핑 카트 액세스를 위해 인증이 필요한 앱이나 일부 페이지에서 데이터를 캐시하는 앱이 있습니다.Examples include an app that requires authentication to access the shopping cart, or an app that caches data on some pages. 작업 메서드 전후로 논리를 수행하려면 필터를 사용합니다.To perform logic before or after an action method, use a filter. 교차 편집 문제에서 필터를 사용하면 중복을 줄일 수 있으므로 DRY(반복 금지) 원칙을 따르도록 할 수 있습니다.Using Filters on cross-cutting concerns can reduce duplication, allowing them to follow the Don't Repeat Yourself (DRY) principle.

[Authorize]와 같은 대부분의 필터 특성은 원하는 세분성 수준에 따라 컨트롤러 또는 작업 수준에 적용할 수 있습니다.Most filter attributes, such as [Authorize], can be applied at the controller or action level depending upon the desired level of granularity.

오류 처리 및 응답 캐시는 종종 교차 편집 문제입니다.Error handling and response caching are often cross-cutting concerns:

많은 교차 편집 문제는 필터 또는 사용자 지정 미들웨어를 사용하여 처리할 수 있습니다.Many cross-cutting concerns can be handled using filters or custom middleware.