ASP.Net Core

Tutorials – ASP.Net Core

Chapter 3: Controllers and Views

In the previous chapters, we explored the foundational concepts of ASP.NET Core, set up our development environment, and created our first ASP.NET Core application. Now, it’s time to delve deeper into the core components that make web applications dynamic and interactive: Controllers and Views.

3.1 Introduction

In this chapter, we will embark on a journey to understand the role of Controllers and Views in ASP.NET Core. These two components are essential for creating web applications that respond to user requests, process data, and present dynamic content.

3.1.1 Objectives

In this chapter, our objectives are as follows:

Understanding Controllers: We will explore the fundamental concepts of controllers, learn how to create and configure them, and understand their role in handling HTTP requests.
Working with Views: We will delve into the world of Views, discovering how they generate HTML responses and how to create and structure them effectively.
Controller-View Interaction: We will unravel the synergy between controllers and views, understanding how they collaborate to provide a seamless user experience.

Let’s begin our journey by unraveling the world of Controllers.

3.2 Controllers

Controllers are the backbone of an ASP.NET Core application. They act as intermediaries between the client’s HTTP request and the application’s response. In essence, controllers handle incoming requests, process data, and determine the appropriate response to send back to the client.

3.2.1 What Are Controllers?

Controllers, in the context of ASP.NET Core, are classes responsible for processing HTTP requests and coordinating the application’s response. They play a pivotal role in implementing the Model-View-Controller (MVC) architectural pattern, a key design principle in ASP.NET Core.

At their core, controllers receive requests, decide which actions to take, and provide responses. These actions can include tasks like fetching data from a database, updating records, or rendering a web page.

3.2.2 Creating Controllers

3.2.2.1 Controller Classes

Controllers are typically represented as classes in your ASP.NET Core project. These classes inherit from the Controller base class or one of its derivatives. The naming convention for controller classes often follows the pattern of appending “Controller” to the logical entity they manage. For example, a controller for managing products might be named ProductController.

Controller classes are usually placed within a folder named “Controllers” in your project’s directory structure. This organization keeps your codebase tidy and makes it easier to locate and manage controllers.

3.2.2.2 Actions

Actions are the individual methods within controller classes. They represent specific endpoints that can be accessed via HTTP requests. Actions are public methods that return an instance of ActionResult or one of its derived types. The ActionResult signifies the result of the action method and determines what type of response will be sent back to the client.

Here’s a simple example of a controller with an action:

public class HomeController : Controller

{

public IActionResult Index()

{

return View();

}

}

In this example, the HomeController class inherits from Controller, and it has an Index action that returns a ViewResult. The ViewResult indicates that this action will render an HTML view and send it as the response.

3.2.3 Routing and Actions

3.2.3.1 Routing Basics

Routing is a fundamental aspect of controller actions. It determines how incoming requests are mapped to specific controller actions. ASP.NET Core uses attribute-based routing, allowing you to define routes directly on the actions using attributes like [Route].

The default route template used by ASP.NET Core is {controller}/{action}/{id?}, which automatically maps the controller name, action name, and an optional parameter (usually an ID) from the URL to the corresponding action method. For example, a URL like /Home/Index would be mapped to the Index action within the HomeController.

You can also customize routes to match specific URL patterns or include additional route parameters. This level of flexibility allows you to design clean and user-friendly URLs for your application.

3.2.3.2 Action Parameters

Actions can accept parameters to retrieve data from the request, such as form data, query parameters, or route values. These parameters are automatically populated by ASP.NET Core through a process called model binding.

Here’s an example of an action with parameters:

public class ProductController : Controller { public IActionResult Details(int id) { // Fetch product details based on the 'id' parameter. var product = ProductService.GetProductById(id);

// Return a ViewResult with the product data. return View(product); } }

In this example, the Details action takes an int parameter named id. ASP.NET Core’s model binding mechanism automatically extracts the id from the route or query string and provides it as an argument to the action method.

3.2.4 Action Results

3.2.4.1 ActionResult

The base class for all action results in ASP.NET Core is ActionResult. It represents the result of an action method and can be used to return various types of responses, including HTML views, JSON data, or redirects.

By returning different types of ActionResult, you can dynamically generate diverse responses based on the request or the application’s logic.

3.2.4.2 ViewResult

ViewResult is a commonly used ActionResult for rendering HTML views. It corresponds to a Razor view file (typically with a .cshtml extension) that generates HTML content.

Here’s an example of an action that returns a ViewResult:

public IActionResult Index() { // Retrieve a list of products from the database. var products = ProductService.GetAllProducts();

// Pass the list of products to the view. return View(products); }

In this example, the Index action retrieves a list of products and passes it to the associated view. The view, written in Razor syntax, can then use this data to dynamically generate the HTML to display to the user.

3.2.4.3 JsonResult

JsonResult is another type of ActionResult used to return JSON-formatted data. It’s commonly employed in AJAX requests or when providing data to a client-side application.

Here’s a simplified example of an action that returns JSON data:

public IActionResult GetProduct(int id) { // Retrieve product details as an object. var product = ProductService.GetProductById(id);

// Return the product data as JSON. return Json(product); }

In this case, the GetProduct action fetches product details and returns them as JSON. This is particularly useful when your application needs to communicate with JavaScript on the client side.

3.2.5 Controller Lifecycle

Controllers have a well-defined lifecycle within an ASP.NET Core application. This lifecycle includes instantiation, execution of action methods, and eventual disposal. Understanding the controller lifecycle can be beneficial when implementing custom logic that requires certain actions to be performed at specific points in the process.

3.2.5.1 Instantiation

When an HTTP request is made to your application, ASP.NET Core automatically creates an instance of the appropriate controller class to handle the request. This controller instance is created by the Dependency Injection (DI) container, which is configured during application startup.

3.2.5.2 Action Method Execution

Once the controller instance is created, ASP.NET Core identifies and invokes the action method that corresponds to the incoming request. The action method processes the request and returns an ActionResult.

During this phase, you have the opportunity to perform various tasks, such as data retrieval, validation, or authentication.

3.2.5.3 Disposal

After the action method has executed and the response has been sent to the client, the controller instance is disposed of. This ensures that resources are released and memory is reclaimed efficiently.

You can override controller lifecycle methods, such as OnActionExecuting and OnActionExecuted, to inject custom logic at specific points in the controller’s lifecycle. These methods allow you to execute code before and after action method execution, providing greater control over the request-handling process.

3.3 Views

Views are responsible for generating the HTML responses that are sent to the client’s web browser. They define the user interface, layout, and content presentation of your web application. Views are typically written in Razor syntax, a blend of HTML markup and C# code that allows for dynamic content generation.

3.3.1 What Are Views?

In the context of ASP.NET Core, views are the visual representation of your application’s data and logic. They determine how information is presented to users in their web browsers. A view can range from a simple HTML page to a complex layout containing dynamic data and interactive elements.

Views play a pivotal role in ensuring that your web application delivers an engaging and user-friendly experience. They separate the presentation layer from the business logic, adhering to the principles of the MVC architectural pattern.

3.3.2 Creating Views

3.3.2.1 Razor Views

The most common type of view in ASP.NET Core is the Razor view. Razor views have the file extension .cshtml, indicating their use of both HTML and C# code. This combination of languages enables you to embed dynamic content, execute logic, and render data from your controller actions.

Razor views are typically organized within a folder named “Views” in your project’s directory structure. Furthermore, they are further structured by the controller they are associated with. For instance, if you have a HomeController, its views will be placed in a “Home” folder within the “Views” directory.

3.3.2.2 Layouts

Layouts in ASP.NET Core provide a consistent structure for your views, including elements like headers, footers, navigation menus, and sidebars. Rather than duplicating these elements across multiple views, you can create a shared layout file, often named _Layout.cshtml, that other views can inherit from.

Layouts are instrumental in maintaining a cohesive and uniform look and feel throughout your web application. By encapsulating the common structural elements in a layout, you ensure that design changes or updates can be made in one place and propagate seamlessly to all views that use that layout.

3.3.3 ViewData and ViewBag

ViewData and ViewBag are mechanisms for passing data from controllers to views. They enable you to send information that should be displayed in the view, such as dynamic content, error messages, or user-specific details.

3.3.3.1 ViewData

ViewData is a key-value dictionary that allows you to store and transfer data from a controller to its associated view. It is a dynamic object, which means that you can use any valid C# identifier as a key.

Here’s an example of how to set data in ViewData within a controller action:

public IActionResult Index()

{

ViewData["Message"] = "Welcome to our website!";

return View();

}

In this example, the controller sets a message in ViewData, which can then be accessed and displayed in the associated view.

3.3.3.2 ViewBag

ViewBag is another dynamic container for passing data from controllers to views. It is a dynamic property bag that simplifies data sharing between controller actions and views.

Here’s how to use ViewBag in a controller action:

public IActionResult Index()

{

ViewBag.Message = "Welcome to our website!";

return View();

}

Like ViewData, you can access the data stored in ViewBag within the view and render it as needed.

3.4 Controller-View Interaction

The interaction between controllers and views is at the heart of building dynamic web applications with ASP.NET Core. Controllers receive incoming requests, process data, and decide which view to render as the response. Views, in turn, generate the HTML markup that is sent back to the client’s web browser.

3.4.1 Controller Passing Data to Views

One of the primary responsibilities of controllers is to pass data to views. Controllers can fetch data from various sources, such as databases, APIs, or user input, and make this data available to views.

Here’s an example of a controller action that passes a list of products to a view:

public IActionResult Products()

{

var products = ProductService.GetAllProducts();

return View(products);

}

In this example, the Products action retrieves a list of products from a service or database and passes it to the associated view using return View(products). The view can then iterate over this data and generate HTML for each product.

3.4.2 Views Rendering HTML

Views are responsible for rendering HTML content based on the data and logic provided by the controller. They use Razor syntax to combine HTML markup with C# code to create dynamic web pages.

Here’s a simplified example of a Razor view that displays a list of products passed from a controller:

@model List<Product>

<!DOCTYPE html>
<html>
<head>
<title>Product List</title>
</head>
<body>
<h1>Product List</h1>

<ul> @foreach (var product in Model) { <li>@product.Name - @product.Price</li> } </ul> </body> </html>

In this view, @model List<Product> defines the type of data that the view expects (a list of products). The @foreach loop iterates through the products and generates an HTML list item for each one.

3.4.3 Controller Deciding the View

Controllers also play a pivotal role in determining which view should be rendered as the response to a specific request. By default, ASP.NET Core follows naming conventions to pair controllers with views. For instance, the HomeController typically corresponds to views in a folder named “Home.”

However, you can explicitly specify the view to be rendered using the View method in a controller action. Here’s an example:

public IActionResult CustomView()

{

return View("MyCustomView");

}

In this example, the CustomView action specifies that the “MyCustomView” view should be rendered, overriding the default naming convention.

3.4.4 View Models

In many cases, it’s beneficial to use view models to encapsulate the data and behavior needed by a view. View models are custom classes that consolidate the specific data required for rendering a view. They provide a structured and type-safe way to pass data between controllers and views.

Here’s an example of a simple view model:

public class ProductViewModel

{

public int Id { get; set; }

public string Name { get; set; }

public decimal Price { get; set; }

}

Controllers can create instances of view models, populate them with data, and pass them to views for rendering.

3.5 Conclusion of Chapter 3

In this chapter, we’ve embarked on a comprehensive exploration of Controllers and Views in ASP.NET Core. We’ve learned that controllers are the bridge between HTTP requests and responses, handling data processing and routing. Views, on the other hand, are responsible for generating HTML content and presenting it to users.

Throughout this chapter, we’ve covered the following key concepts:

The creation of controllers and actions to handle incoming requests.
Routing and parameter handling to route requests to the appropriate actions.
Various types of action results, including ViewResult and JsonResult, to generate responses.
The lifecycle of controllers, including instantiation and disposal.
The creation of views using Razor syntax, layouts, and the rendering of dynamic content.
Techniques for passing data from controllers to views using ViewData and ViewBag.
The pivotal role of view models in structuring data for views.

With a solid understanding of Controllers and Views, you’re well-equipped to create dynamic web applications in ASP.NET Core. In the next chapter, we will delve into the topic of data access and explore how to interact with databases to retrieve and manipulate data.

Congratulations! You’ve completed Chapter 3, gaining a deep understanding of Controllers and Views in ASP.NET Core. In the upcoming chapters, we’ll continue our journey by exploring data access, authentication, and other crucial aspects of web development with ASP.NET Core.