Model–view–controller (MVC) separates an application’s data and business logic from the UI that presents them. A controller handles a user interaction, works with the model, and supplies data for a view. Keeping these responsibilities apart makes components easier to change and test. section 13.3 section 13.4.4
For a server-rendered page, each part has a distinct job:
- The model holds application data and performs business logic, often accessed through a service. section 13.3 section 13.4.4
- The controller receives the request, fetches or updates model data, and chooses a response. In Razor Pages, a page handler fills this role. section 13.3
- The view uses the data it receives to generate the UI. A Razor view generates HTML. section 13.2 section 13.3
A category page request
Suppose someone requests a to-do list category. The OnGet handler receives the category, asks ToDoService for matching items, and exposes them through its Items property. The Razor view reads those items and generates the HTML response. The handler coordinates the work; it does not generate the HTML or own the business logic. section 13.2 section 13.4.4
Listing 13.5 A Razor Page for viewing all to-do items in a given category
public class CategoryModel : PageModel
{
private readonly ToDoService _service; #1
public CategoryModel(ToDoService service) #1
{
_service = service;
}
public ActionResult OnGet(string category) #2
{
Items = _service.GetItemsForCategory(category); #3
return Page(); #4
}
public List<ToDoListModel> Items { get; set; } #5
}
The CategoryModel listing shows the controller role in code: OnGet calls an injected service, stores the result in Items, and returns the page. section 13.2
MVC is a pattern, not a requirement to use classes named Model, View, and Controller. Razor Pages follows it with page handlers and Razor views; ASP.NET Core MVC uses controllers and action methods instead. The two approaches are architecturally similar, though their project structures differ. Web API controllers use the same underlying framework and can follow the pattern without rendering server-side HTML. section 13.4 section 19.5 section 20.2
The practical payoff is reduced coupling: a change to HTML generation need not require a change to business logic. MVC is a broad pattern with different interpretations, so focus on the boundaries between responsibilities rather than a single prescribed project layout. section 13.4.4 section 13.3
