컨트롤러: 컨트롤러 액션으로 라우팅하기

라우팅 미들웨어 설정하기

프로젝트 루트에 위치한 Startup.cs 파일의 Configure 메서드를 살펴보면 다음과 비슷한 코드를 확인할 수 있습니다:

app.UseMvc(routes =>
{
    routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");
});

이 코드의 UseMvc 메서드 호출 내부에서는 MapRoute 메서드를 이용해서 default라는 단일 라우트를 생성하고 있습니다. 대부분의 MVC 응용 프로그램들은 이 default 라우트와 비슷한 템플릿을 라우트로 사용하게 됩니다.

"{controller=Home}/{action=Index}/{id?}"라는 라우트 템플릿은 /Products/Details/5 등의 URL 경로와 일치하며, 경로의 토큰화를 통해서 { controller = Products, action = Details, id = 5 } 같은 라우트 값들을 추출합니다. 그에 따라 MVC는 ProductsController라는 이름의 컨트롤러를 찾아서 Details 액션을 실행하려고 시도하게 됩니다:

public class ProductsController : Controller
{
    public IActionResult Details(int id) { ... }
}

이번 예제에서 한 가지 유념해야 할 부분은, 액션이 실행될 때 모델 바인딩이 id = 5 값을 이용해서 id 매개변수의 값을 5로 설정해준다는 사실입니다. 보다 자세한 정보는 모델 바인딩 문서를 참고하시기 바랍니다.

이렇게 default 라우트를 사용할 경우:

routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");

라우트 템플릿의:

• {controller=Home} 부분은 Home을 기본 controller 값으로 정의하고,
• {action=Index} 부분은 Index를 기본 action 값으로 정의하고,
• {id?} 부분은 id를 선택적 값으로 정의합니다.

기본 라우트 매개변수나 선택적 라우트 매개변수로 정의된 세그먼트는 매칭을 위해서 URL 경로에 반드시 제공돼야 할 필요가 없습니다. 라우트 템플릿 구문에 대한 보다 자세한 설명은 Routing 문서를 참고하시기 바랍니다.

예를 들어서, "{controller=Home}/{action=Index}/{id?}" 라우트 템플릿은 URL 경로 /와 일치하며 { controller = Home, action = Index }라는 라우트 값들을 만들어내게 됩니다. 즉, controller 및 action 값으로는 기본값이 사용되고, id는 해당하는 세그먼트가 URL 경로에 존재하지 않으므로 값이 생성되지 않습니다. MVC는 이 라우트 값들을 이용해서 HomeController의 Index 액션을 선택하게 됩니다:

public class HomeController : Controller
{
    public IActionResult Index() { ... }
}

지금까지 살펴본 컨트롤러 정의와 라우트 템플릿을 사용할 경우, 다음과 같은 URL 경로들 중 한 가지가 요청되면 HomeController.Index 액션이 실행됩니다:

• /Home/Index/17
• /Home/Index
• /Home
• /

또한, 다음과 같이 UseMvcWithDefaultRoute 메서드를 사용하면:

app.UseMvcWithDefaultRoute();

간편하게 다음 코드를 대체할 수 있습니다:

app.UseMvc(routes =>
{
    routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");
});

UseMvc 메서드와 UseMvcWithDefaultRoute 메서드는 모두 미들웨어 파이프라인에 RouterMiddleware의 인스턴스를 추가합니다. MVC는 미들웨어와 직접적으로 상호 작용하지 않으며, 라우팅을 통해서 요청을 처리합니다. MVC는 MvcRouteHandler의 인스턴스를 통해서 라우트와 연결됩니다. UseMvc 메서드의 내부 코드는 다음과 비슷하게 구현되어 있습니다:

var routes = new RouteBuilder(app);

// Add connection to MVC, will be hooked up by calls to MapRoute.
routes.DefaultHandler = new MvcRouteHandler(...);

// Execute callback to register routes.
// routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");

// Create route collection and add the middleware.
app.UseRouter(routes.Build());

UseMvc 메서드는 직접적으로 어떠한 라우트도 정의하지 않으며, 어트리뷰트 라우트를 지원하기 위한 라우트 컬렉션의 자리 표시자(Placeholder)를 추가합니다. 재정의된 UseMvc(Action<IRouteBuilder>) 메서드를 사용하면 필요한 라우트를 추가하고 어트리뷰트 라우팅도 지원할 수 있습니다. UseMvc 메서드 및 모든 변형 메서드들은 내부적으로 어트리뷰트 라우트를 지원하기 위한 자리 표시자를 추가해주기 때문에, UseMvc 메서드의 구성 방식과는 무관하게 언제나 어트리뷰트 라우팅을 사용할 수 있습니다. UseMvcWithDefaultRoute 메서드는 기본 디폴트 라우트를 정의하고 어트리뷰트 라우팅에 대한 지원을 추가합니다. 어트리뷰트 라우팅에 대한 보다 자세한 내용들은 어트리뷰트 라우팅 절에서 살펴보겠습니다.

기본 라우팅

이전 절에서 살펴본 default 라우트는 기본 라우팅(Conventional Routing)의 한 예입니다:

routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");

이런 형태의 라우팅을 기본(규약적) 라우팅이라고 부르는데, 그 이유는 다음과 같이 URL 경로에 대한 규약(Convention)을 규정하기 때문입니다:

• 첫 번째 경로 세그먼트를 컨트롤러 이름에 매핑합니다.
• 두 번째 경로 세그먼트를 액션 이름에 매핑합니다.
• 세 번째 세그먼트는 모델 엔터티에 매핑되는 선택적 id에 사용됩니다.

이 default 라우트를 사용하면, /Products/List라는 URL 경로는 ProductsController.List 액션에 매핑되고, /Blog/Article/17이라는 URL 경로는 BlogController.Article 액션에 매핑됩니다. 이 매핑은 오직 컨트롤러와 액션의 이름을 기반으로 성립되며, 네임스페이스나 소스 파일의 위치, 혹은 메서드의 매개변수와는 아무런 상관이 없습니다.

다중 라우트

다음과 같이 UseMvc 메서드 내부에 더 많은 MapRoute 메서드 호출을 추가해서 다중 라우트를 추가할 수 있습니다. 그러면 다중으로 규약을 정의하거나, 특정 액션 전용의 기본 라우팅를 추가할 수 있습니다:

app.UseMvc(routes =>
{
    routes.MapRoute("blog", "blog/{*article}",
           defaults: new { controller = "Blog", action = "Article" });
    routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");
});

이 코드의 blog 라우트는 전용 기본 라우트(Dedicated Conventional Route)로, 이는 기본 라우팅 시스템을 이용하기는 하지만, 특정 액션 전용의 라우트라는 뜻입니다. 라우트 템플릿에 controller와 action이 매개변수로 지정되지 않았기 때문에 항상 기본값이 사용되며, 그 결과 이 라우트는 항상 BlogController.Article 액션으로만 매핑됩니다.

라우트 컬렉션의 라우트들은 순서를 갖고 있으며, 코드로 추가된 순서대로 처리됩니다. 따라서 이번 예제에서는 blog 라우트가 default 라우트보다 먼저 시도됩니다.

public class ProductsController : Controller
{
    public IActionResult Edit(int id) { ... }

    [HttpPost]
    public IActionResult Edit(int id, Product product) { ... }
}

app.UseMvc(routes =>
{
    routes.MapRoute("blog", "blog/{*article}",
        defaults: new { controller = "Blog", action = "Article" });
    routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");
});

어트리뷰트 라우팅

어트리뷰트 라우팅은 어트리뷰트들의 모음을 사용해서 액션을 라우트 템플릿과 직접 매핑합니다. 다음 예제 코드는 Configure 메서드에서 app.UseMvc();를 호출해서 아무런 라우트도 전달하지 않았다고 가정합니다. 그럼에도 불구하고 이 HomeController는 default 라우트 템플릿인 {controller=Home}/{action=Index}/{id?} 템플릿과 일치하는 URL들과 동일한 일련의 URL들과 일치하게 됩니다:

public class HomeController : Controller
{
    [Route("")]
    [Route("Home")]
    [Route("Home/Index")]
    public IActionResult Index()
    {
        return View();
    }
    [Route("Home/About")]
    public IActionResult About()
    {
        return View();
    }
    [Route("Home/Contact")]
    public IActionResult Contact()
    {
        return View();
    }
}

가령 HomeController.Index() 액션은 /, /Home, 또는 /Home/Index URL 경로 중 하나가 요청되면 실행됩니다.

어트리뷰트 라우팅에서는 컨트롤러 이름과 액션 이름은 액션을 선택할 때 아무런 역할을 수행하지 않습니다. 다음 예제 코드는 이전 예제 코드와 동일한 URL들과 일치합니다:

public class MyDemoController : Controller
{
    [Route("")]
    [Route("Home")]
    [Route("Home/Index")]
    public IActionResult MyIndex()
    {
        return View("Index");
    }
    [Route("Home/About")]
    public IActionResult MyAbout()
    {
        return View("About");
    }
    [Route("Home/Contact")]
    public IActionResult MyContact()
    {
        return View("Contact");
    }
}

어트리뷰트 라우팅은 HttpPostAttribute 같은 HTTP[Verb] 어트리뷰트를 통해서도 사용이 가능합니다. 이 유형의 모든 어트리뷰트들은 라우트 템플릿을 전달받을 수 있습니다. 다음 예제 코드는 동일한 라우트 템플릿과 일치하는 두 가지 액션을 보여줍니다:

[HttpGet("/products")]
public IActionResult ListProducts()
{
    // ...
}

[HttpPost("/products")]
public IActionResult CreateProduct(...)
{
    // ...
}

즉, /products라는 URL 경로에 대해서, HTTP 동사가 GET인 경우에는 ProductsApi.ListProducts 액션이 실행되고, HTTP 동사가 POST인 경우에는 ProductsApi.CreateProduct 액션이 실행됩니다. 어트리뷰트 라우팅은 먼저 라우트 어트리뷰트에 의해서 정의된 라우트 템플릿들의 모음을 대상으로 URL이 일치하는지 확인합니다. 만약 라우트 템플릿이 일치하면 IActionConstraint 제약이 적용되어 실행될 액션이 결정됩니다.

어트리뷰트 라우트는 특정 액션에 적용되기 때문에, 라우트 템플릿 정의에서 필수 매개변수를 지정하기가 더 쉽습니다. 다음 예제의 경우, id 매개변수는 URL 경로에 필수로 지정되어야 합니다:

public class ProductsApiController : Controller
{
    [HttpGet("/products/{id}", Name = "Products_List")]
    public IActionResult GetProduct(int id) { ... }
}

이 ProductsApi.GetProducts(int) 액션은 /products/3 같은 URL 경로가 요청된 경우에는 실행되지만, /products 같은 경로가 요청된 경우에는 실행되지 않습니다. 라우트 템플릿과 관련 옵션들에 대한 전체 설명은 Routing 문서를 참고하시기 바랍니다.

이 라우트 어트리뷰트는 Products_List라는 라우트 이름을 함께 정의하고 있습니다. 라우트 이름은 특정 라우트에 기반한 URL을 생성할 때 사용됩니다. 라우트 이름은 라우팅의 URL 일치 확인 작업에는 아무런 영향도 미치지 않으며, 오직 URL 생성 시에만 사용됩니다. 라우트 이름은 응용 프로그램 수준에서 유일해야 합니다.

[Route("products")]
public class ProductsApiController : Controller
{
    [HttpGet]
    public IActionResult ListProducts() { ... }

    [HttpGet("{id}")]
    public ActionResult GetProduct(int id) { ... }
}

[Route("Home")]
public class HomeController : Controller
{
    [Route("")]      // Combines to define the route template "Home"
    [Route("Index")] // Combines to define the route template "Home/Index"
    [Route("/")]     // Does not combine, defines the route template ""
    public IActionResult Index()
    {
        ViewData["Message"] = "Home index";
        var url = Url.Action("Index", "Home");
        ViewData["Message"] = "Home index" + "var url = Url.Action; =  " + url;
        return View();
    }

    [Route("About")] // Combines to define the route template "Home/About"
    public IActionResult About()
    {
        return View();
    }   
}

라우트 템플릿 토큰 대체 ([controller], [action], [area])

어트리뷰트 라우트는 작업의 편의를 위해 토큰을 대괄호([, ]])로 감싸는 토큰 대체(Token Replacement) 기능을 제공해줍니다. [action], [area], 그리고 [controller] 토큰은 라우트가 정의된 액션에 대응하는 액션 이름, 영역 이름, 그리고 컨트롤러 이름 값으로 대체됩니다. 다음 예제 코드의 액션들은 주석에 설명된 URL 경로들과 일치합니다:

[Route("[controller]/[action]")]
public class ProductsController : Controller
{
    [HttpGet] // Matches '/Products/List'
    public IActionResult List() {
        // ...
    }

    [HttpGet("{id}")] // Matches '/Products/Edit/{id}'
    public IActionResult Edit(int id) {
        // ...
    }
}

토큰 대체는 어트리뷰트 라우트를 구성하는 마지막 단계에서 수행됩니다. 위의 예제 코드는 다음 코드와 동일하게 동작합니다:

public class ProductsController : Controller
{
    [HttpGet("[controller]/[action]")] // Matches '/Products/List'
    public IActionResult List() {
        // ...
    }

    [HttpGet("[controller]/[action]/{id}")] // Matches '/Products/Edit/{id}'
    public IActionResult Edit(int id) {
        // ...
    }
}

어트리뷰트 라우트는 상속되는 경우에도 결합이 가능합니다. 이런 특징은 토큰 대체와 함께 사용될 때 특히 강력한 결과를 이끌어냅니다.

[Route("api/[controller]")]
public abstract class MyBaseController : Controller { ... }

public class ProductsController : MyBaseController
{
    [HttpGet] // Matches '/api/Products'
    public IActionResult List() { ... }

    [HttpPost("{id}")] // Matches '/api/Products/{id}'
    public IActionResult Edit(int id) { ... }
}

토큰 대체를 어트리뷰트 라우트에 의해서 정의되는 라우트 이름에도 적용할 수 있습니다. 가령, [Route("[controller]/[action]", Name="[controller]_[action]")]와 같이 어트리뷰트를 지정하면 각각의 액션마다 유일한 라우트 이름이 생성됩니다.

[Route("[controller]")]
public class ProductsController : Controller
{
    [Route("")]     // Matches 'Products'
    [Route("Index")] // Matches 'Products/Index'
    public IActionResult Index()
}

[Route("Store")]
[Route("[controller]")]
public class ProductsController : Controller
{
    [HttpPost("Buy")]      // Matches 'Products/Buy' and 'Store/Buy'
    [HttpPost("Checkout")] // Matches 'Products/Checkout' and 'Store/Checkout'
    public IActionResult Buy()
}

[Route("api/[controller]")]
public class ProductsController : Controller
{
    [HttpPut("Buy")]      // Matches PUT 'api/Products/Buy'
    [HttpPost("Checkout")] // Matches POST 'api/Products/Checkout'
    public IActionResult Buy()
}

public class MyApiControllerAttribute : Attribute, IRouteTemplateProvider
{
    public string Template => "api/[controller]";

    public int? Order { get; set; }

    public string Name { get; set; }
}

using Microsoft.AspNetCore.Mvc.ApplicationModels;
using System.Linq;
using System.Text;

public class NamespaceRoutingConvention : IControllerModelConvention
{
    private readonly string _baseNamespace;

    public NamespaceRoutingConvention(string baseNamespace)
    {
        _baseNamespace = baseNamespace;
    }

    public void Apply(ControllerModel controller)
    {
        var hasRouteAttributes = controller.Selectors.Any(selector =>
                                                selector.AttributeRouteModel != null);
        if (hasRouteAttributes)
        {
            // This controller manually defined some routes, so treat this 
            // as an override and not apply the convention here.
            return;
        }

        // Use the namespace and controller name to infer a route for the controller.
        //
        // Example:
        //
        //  controller.ControllerTypeInfo ->    "My.Application.Admin.UsersController"
        //  baseNamespace ->                    "My.Application"
        //
        //  template =>                         "Admin/[controller]"
        //
        // This makes your routes roughly line up with the folder structure of your project.
        //
        var namespc = controller.ControllerType.Namespace;

        var template = new StringBuilder();
        template.Append(namespc, _baseNamespace.Length + 1,
                        namespc.Length - _baseNamespace.Length - 1);
        template.Replace('.', '/');
        template.Append("/[controller]");

        foreach (var selector in controller.Selectors)
        {
            selector.AttributeRouteModel = new AttributeRouteModel()
            {
                Template = template.ToString()
            };
        }
    }
}

혼합 라우팅

MVC 응용 프로그램에서는 기본 라우팅과 어트리뷰트 라우팅을 섞어서 사용할 수 있습니다. 일반적으로 브라우저에 HTML 페이지를 제공하는 컨트롤러에서는 기본 라우팅을 사용하고, REST APIs를 제공하는 컨트롤러에서는 어트리뷰트 라우팅을 사용합니다.

액션은 기본 라우트나 어트리뷰트 라우트 중 한 가지를 사용하게 됩니다. 컨트롤러나 액션에 라우트를 지정하는 것은 어트리뷰트 라우팅을 사용하겠다는 의미가 됩니다. 어트리뷰트 라우트가 정의된 액션은 기본 라우팅을 통해서는 접근이 불가능하며, 그 반대 역시 마찬가지 입니다. 컨트롤러에 지정된 모든 라우트 어트리뷰트는 해당 컨트롤러의 모든 액션들이 어트리뷰트로 라우트 되도록 만듭니다.

URL 생성

MVC 응용 프로그램에서는 라우팅의 URL 생성 기능을 이용해서 액션에 대한 URL 링크를 생성할 수 있습니다. URL 생성 기능을 활용하면 하드코딩 되는 URL들을 줄이면서, 더 견고하며 유지보수가 용이한 코드를 만들 수 있습니다. 이번 절에서는 MVC가 제공하는 URL 생성 기능을 집중적으로 살펴보고, 기초적인 URL 생성 작업 방법을 알아보겠습니다. URL 생성에 대한 더 자세한 설명은 Routing 문서를 참고하시기 바랍니다.

IUrlHelper 인터페이스는 URL을 생성하기 위한 MVC와 라우팅 간의 기반구조를 구성하는 핵심 요소입니다. 컨트롤러, 뷰, 그리고 뷰 구성 요소에서는 Url 속성을 통해서 IUrlHelper의 인스턴스를 사용할 수 있습니다.

다음 예제에서는 IUrlHelper 인터페이스를 구현하고 있는 Controller.Url 속성을 이용해서 다른 액션을 가르키는 URL을 생성하고 있습니다.

using Microsoft.AspNetCore.Mvc;

public class UrlGenerationController : Controller
{
    public IActionResult Source()
    {
        // Generates /UrlGeneration/Destination
        var url = Url.Action("Destination");
        return Content($"Go check out {url}, it's really great.");
    }

    public IActionResult Destination()
    {
        return View();
    }
}

만약 응용 프로그램이 default 기본 라우트를 사용하고 있다면, 이 예제 코드의 url 변수에 /UrlGeneration/Destination URL 경로 문자열이 값으로 할당됩니다. 이 URL 경로는 현재 요청으로부터 가져온 라우트 값들(주변값, Ambient Values)과 Url.Action 메서드에 전달된 값들을 조합한 결과를 이용해서, 라우트 템플릿의 해당 값을 대체하는 방식으로 라우팅에 의해 생성된 것입니다:

주변값: { controller = "UrlGeneration", action = "Source" }
Url.Action에 전달된 값: { controller = "UrlGeneration", action = "Destination" }
라우트 템플릿: {controller}/{action}/{id?}

결과값: /UrlGeneration/Destination

라우트 템플릿의 각 라우트 매개변수들은 이름이 일치하는 전달된 값이나 주변값으로 그 값이 대체됩니다. 값이 존재하지 않는 라우트 매개변수는 기본값이 존재할 경우 기본값이 사용되며, 선택적 매개변수인 경우에는 생략됩니다 (이번 예제의 id 매개변수처럼). 그러나 만약 필수 라우트 매개변수에 대응하는 값이 하나라도 존재하지 않으면 URL 생성은 실패하게 됩니다. 특정 라우트를 이용한 URL 생성이 실패할 경우, 모든 라우트들이 실패하거나 일치하는 라우트가 발견될 때까지 계속해서 다음 라우트가 시도됩니다.

이 Url.Action 예제는 기본 라우팅을 가정하고 있습니다. 그러나 어트리뷰트 라우팅을 사용하는 경우에도 내부 개념은 다소 다르지만 비슷한 방식으로 URL을 생성할 수 있습니다. 기본 라우팅에서는 라우트 값들을 이용해서 템플릿을 확장하며, 대부분 템플릿에 controller와 action에 대한 라우트 값들이 사용됩니다. 이 방식이 동작하는 이유는 라우팅에 의해 매치되는 URL들이 <>규약을 준수하기 때문입니다. 그러나 어트리뷰트 라우팅에서는 템플릿에 controller와 action에 대한 라우트 값을 사용할 수 없으며, 대신 사용할 템플릿을 찾는데 사용됩니다.

다음은 어트리뷰트 라우팅을 사용하는 예제를 보여줍니다:

// In Startup class
public void Configure(IApplicationBuilder app)
{
    app.UseMvc();
}

using Microsoft.AspNetCore.Mvc;

public class UrlGenerationController : Controller
{
    [HttpGet("")]
    public IActionResult Source()
    {
        var url = Url.Action("Destination"); // Generates /custom/url/to/destination
        return Content($"Go check out {url}, it's really great.");
    }

    [HttpGet("custom/url/to/destination")]
    public IActionResult Destination() {
        return View();
    }
}

MVC는 어트리뷰트 라우트를 사용하는 모든 액션들의 조회 테이블을 구성해서, URL 생성에 사용할 라우트 템플릿을 선택하기 위해 controller 및 action 값들의 일치 여부를 확인합니다. 이번 예제에서는 custom/url/to/destination이라는 URL이 생성됩니다.

using Microsoft.AspNetCore.Mvc;

public class TestController : Controller
{
    public IActionResult Index()
    {
        // Generates /Products/Buy/17?color=red
        var url = Url.Action("Buy", "Products", new { id = 17, color = "red" });
        return Content(url);
    }
}

using Microsoft.AspNetCore.Mvc;

public class UrlGenerationController : Controller
{
    [HttpGet("")]
    public IActionResult Source()
    {
        var url = Url.RouteUrl("Destination_Route"); // Generates /custom/url/to/destination
        return Content($"See {url}, it's really great.");
    }

    [HttpGet("custom/url/to/destination", Name = "Destination_Route")]
    public IActionResult Destination() {
        return View();
    }
}

public Task<IActionResult> Edit(int id, Customer customer)
{
    if (ModelState.IsValid)
    {
        // Update DB with new details.
        return RedirectToAction("Index");
    }
}

app.UseMvc(routes =>
{
    routes.MapRoute("blog", "blog/{*article}",
        defaults: new { controller = "Blog", action = "Article" });
    routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");
});

영역

영역(Areas)은 관련된 기능들을 분리된 라우팅-이름공간(컨트롤러 액션에 대한)과 폴더 구조(뷰에 대한)의 그룹으로 분할 구성하기 위해서 사용되는 ASP.NET MVC의 기능입니다. 영역을 사용하면 한 응용 프로그램 내부에 서로 다른 영역에 존재하는 동일한 이름을 가진 여러 개의 컨트롤러들이 동시에 존재할 수 있습니다. 영역을 사용하면 controller와 action에 더해서 area라는 또 다른 라우트 매개변수가 추가되어, 라우팅에 대한 계층구조가 만들어집니다. 이번 절에서는 라우팅과 영역이 함께 상호작용하는 방법을 살펴봅니다. 영역을 뷰와 함께 사용하는 보다 자세한 방법은 영역 문서를 참고하시기 바랍니다.

다음 예제는 MVC가 디폴트 기본 라우트와 Blog라는 영역 이름을 가진 영역 라우트(Area Route)를 함께 사용하도록 구성합니다:

app.UseMvc(routes =>
{
    routes.MapAreaRoute("blog_route", "Blog",
        "Manage/{controller}/{action}/{id?}");
    routes.MapRoute("default_route", "{controller}/{action}/{id?}");
});

이 상태에서 /Manage/Users/AddUser라는 URL 경로를 매칭해보면, 첫 번째 라우트에 의해서 { area = Blog, controller = Users, action = AddUser }라는 라우트 값이 얻어집니다. 여기서 area 라우트 값은 area의 기본값에 의해서 만들어지는데, 사실상 위와 같이 MapAreaRoute 메서드로 만든 라우트는 다음 코드로 만든 라우트와 동일합니다:

app.UseMvc(routes =>
{
    routes.MapRoute("blog_route", "Manage/{controller}/{action}/{id?}",
        defaults: new { area = "Blog" }, constraints: new { area = "Blog" });
    routes.MapRoute("default_route", "{controller}/{action}/{id?}");
});

내부적으로 MapAreaRoute 메서드는 전달된 영역의 이름을 이용해서 area에 대한 기본값과 제약조건이 설정된 라우트를 생성하는데, 이번 예제의 경우에는 그 값은 Blog입니다. 그 결과, 설정된 기본값으로 인해서 해당 라우트는 항상 { area = Blog, ... } 값을 만들어내며, 제약조건으로 인해서 URL 생성 시 { area = Blog, ... } 값을 필수로 요구하게 됩니다.

이번 예제의 라우트 값은 다음 액션과 일치합니다:

using Microsoft.AspNetCore.Mvc;

namespace MyApp.Namespace1
{
    [Area("Blog")]
    public class UsersController : Controller
    {
        public IActionResult AddUser()
        {
            return View();
        }        
    }
}

이 컨트롤러 코드에 사용된 AreaAttribute는 해당 컨트롤러가 영역에 속해 있음을 나타내주는데, 여기에서는 Blog 영역에 컨트롤러가 속해 있다는 것을 말해줍니다. [Area] 어트리뷰트가 지정되지 않은 컨트롤러는 어떠한 영역에도 속하지 않으며, 그런 컨트롤러는 라우팅에서 area 라우트 값이 제공되는 경우에는 일치하지 않습니다. 가령, 다음 예제들 중에서 오직 첫 번째 컨트롤러만 { area = Blog, controller = Users, action = AddUser } 라우트 값과 일치합니다.

using Microsoft.AspNetCore.Mvc;

namespace MyApp.Namespace1
{
    [Area("Blog")]
    public class UsersController : Controller
    {
        public IActionResult AddUser()
        {
            return View();
        }        
    }
}

using Microsoft.AspNetCore.Mvc;

namespace MyApp.Namespace2
{
    // Matches { area = Zebra, controller = Users, action = AddUser }
    [Area("Zebra")]
    public class UsersController : Controller
    {
        public IActionResult AddUser()
        {
            return View();
        }        
    }
}

using Microsoft.AspNetCore.Mvc;

namespace MyApp.Namespace3
{
    // Matches { area = string.Empty, controller = Users, action = AddUser }
    // Matches { area = null, controller = Users, action = AddUser }
    // Matches { controller = Users, action = AddUser }
    public class UsersController : Controller
    {
        public IActionResult AddUser()
        {
            return View();
        }
    }
}

첫 번째와 두 번째 컨트롤러는 영역에 속해 있으며, area 라우트 값으로 각 컨트롤러가 속한 영역 이름이 제공되는 경우에만 일치합니다. 반면, 세 번째 컨트롤러는 어떠한 영역에도 속해 있지 않으며, 라우팅에서 area 값이 전달되지 않는 경우에만 일치합니다.

영역 내부에서 액션을 실행하는 경우에는, area의 라우트 값을 URL 생성에 사용할 라우팅의 주변값으로 사용할 수 있습니다. 이는 다음 예제에서 볼 수 있는 것처럼 URL 생성 시에 기본적으로 영역이 자동으로 적용된다는 것을 의미합니다.

app.UseMvc(routes =>
{
    routes.MapAreaRoute("duck_route", "Duck",
        "Manage/{controller}/{action}/{id?}");
    routes.MapRoute("default", "Manage/{controller=Home}/{action=Index}/{id?}");
});

using Microsoft.AspNetCore.Mvc;

namespace MyApp.Namespace4
{
    [Area("Duck")]
    public class UsersController : Controller
    {
        public IActionResult GenerateURLInArea()
        {
            // Uses the 'ambient' value of area
            var url = Url.Action("Index", "Home"); 
            // returns /Manage
            return Content(url);
        }

        public IActionResult GenerateURLOutsideOfArea()
        {
            // Uses the empty value for area
            var url = Url.Action("Index", "Home", new { area = "" }); 
            // returns /Manage/Home/Index
            return Content(url);
        }
    }
}

IActionConstraint 이해하기

비록 IActionConstraint 인터페이스에 친숙하지 않더라도 여러분은 이미 은연중 이 인터페이스를 사용해본 적이 있을 확율이 높습니다. [HttpGet] 어트리뷰트나 비슷한 다른 [Http-VERB] 어트리뷰트들이 액션 메서드의 실행을 제한하기 위해서 IActionConstraint 인터페이스를 구현하고 있기 때문입니다.

public class ProductsController : Controller
{
    [HttpGet]
    public IActionResult Edit() { }

    public IActionResult Edit(...) { }
}

디폴트 기본 라우트를 사용하고 있다고 가정할 경우, /Products/Edit라는 URL 경로는 { controller = Products, action = Edit }라는 값들을 만들어내며, 이 값들은 이 예제 코드의 두 액션 모두와 일치합니다. IActionConstraint 인터페이스의 관점에서 볼 때, 두 액션은 모두 라우트 데이터와 일치하므로 후보로 간주된다고 말할 수 있습니다.

HttpGetAttribute가 실행되면 Edit() 액션은 HTTP GET 동사에 대해서만 일치하고 다른 모든 HTTP 동사들에 대해서는 일치하는 않는 것으로 지정됩니다. 반면 Edit(...) 액션에는 아무런 제약조건도 정의되어 있지 않기 때문에 모든 HTTP 동사와 일치합니다. 결과적으로 POST 동사는 Edit(...) 액션에 대해서만 일치한다고 봐도 무방합니다. GET 동사의 경우에는 여전히 두 액션 모두와 일치하지만, IActionConstraint 인터페이스가 적용된 액션은 그렇지 않은 액션보다 항상 우선순위가 높은 것으로 간주됩니다. 따라서 두 액션이 모두 일치하더라도Edit() 액션에는 [HttpGet] 어트리뷰트가 지정되어 있기 때문에 더 적합한 것으로 판단되어 이 액션이 선택됩니다.

개념적으로 IActionConstraint 인터페이스는 오버로딩의 한 형태이긴 하지만, 동일한 이름을 가진 메서드들 간의 오버로딩이 아닌, 동일한 URL과 일치하는 액션들 간의 오버로딩입니다. 어트리뷰트 라우팅에서도 IActionConstraint 인터페이스가 사용되므로, 결과적으로 서로 다른 컨트롤러에 위치한 액션들이 동시에 후보로 간주될 수도 있습니다.

public class CountrySpecificAttribute : Attribute, IActionConstraint
{
    private readonly string _countryCode;

    public CountrySpecificAttribute(string countryCode)
    {
        _countryCode = countryCode;
    }

    public int Order
    {
        get
        {
            return 0;
        }
    }

    public bool Accept(ActionConstraintContext context)
    {
        return string.Equals(
            context.RouteContext.RouteData.Values["country"].ToString(),
            _countryCode,
            StringComparison.OrdinalIgnoreCase);
    }
}