Controllers and Routing

Controllers predefined properties

When a routing rule selects a controller and an action method, as a first step, the controller is created. This controller is passed properties extracted from the current request HttpContext. More specifically, the following properties are filled in:

• HttpContext that contains the current request HttpContext.
• Request that contains the current HttpRequest. It is useful to get information on the request URL, and mainly to get the cookies sent from the Browser.
• Response that contains the current HttpResponse being built. Since the response is automatically built by the framework, it is useful, mainly to add cookies to the response.
• User that contains a ClaimsPrincipal instance filled with information about the currently logged user.
• TempData that we used in the example at the start of this chapter. As discussed in that example, and in previous lessons it is used to pass temporary information to the next request, or, analogously, to retrieve some information passed from the previous request. Under the curtain, it is implemented with cookies.

The RouteData property is not taken from the current request HttpContext, but contains information on the routing rule that caused the invocation on the controller and contains also all routing rule parameters’ instantiations. We should never use this property since routing is handled automatically by the framework.

The MetaData dictionary, instead, is not filled when the controller is created, but after the framework has validated all action-method parameters, it is filled with all validation errors. We already used it in the example at the beginning of the chapter.

The controller also contains the same ViewData and ViewBag properties of the views and Razor pages. These properties contain exactly the same dictionary used by the view invoked by the controller, so they are an additional way to pass data to the View. But, it is best practice to avoid their usage in the controller, since controllers should communicate with their view just through the view ViewModel. However, as we have already seen in most of our examples, they are the preferred way for a view to communicate with its layout view.

When it is created, each controller also receives utility objects that are part of the framework. Among them, the Url property contains the same IUrlHelper instance that is available in the analogous property of the views. As already discussed in previous lessons it contains the Action method we can use to get a URL that corresponds to a given action method, controller, and route parameters.

The controller is also passed the framework services that extract information from model attributes and extract the action method input parameters, namely: MetadataProvider, and ModelBinderFactory. We should never use them.

How routing works

Routing is performed by two modules added to the ASP.NET Core pipeline that is defined by the Configure method in the Startup.cs file, namely UseRouting and UseEndpoints, as shown below: