Skip to content

Light Freshness Edit: ASP.NET - mvc #37085

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
lootle1 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Light Freshness Edit: ASP.NET - mvc #37085

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions aspnetcore/mvc/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: Overview of ASP.NET Core MVC
author: ardalis
description: Learn how ASP.NET Core MVC is a rich framework for building web apps and APIs using the Model-View-Controller design pattern.
ms.author: tdykstra
ms.date: 02/12/2020
ms.date: 04/29/2026
uid: mvc/overview
---
# Overview of ASP.NET Core MVC
Expand All @@ -14,7 +14,7 @@ ASP.NET Core MVC is a rich framework for building web apps and APIs using the Mo

## MVC pattern

The Model-View-Controller (MVC) architectural pattern separates an application into three main groups of components: Models, Views, and Controllers. This pattern helps to achieve [separation of concerns](/dotnet/standard/modern-web-apps-azure-architecture/architectural-principles#separation-of-concerns). Using this pattern, user requests are routed to a Controller which is responsible for working with the Model to perform user actions and/or retrieve results of queries. The Controller chooses the View to display to the user, and provides it with any Model data it requires.
The Model-View-Controller (MVC) architectural pattern separates an application into three main groups of components: Models, Views, and Controllers. This pattern helps to achieve [separation of concerns](/dotnet/architecture/modern-web-apps-azure/architectural-principles#separation-of-concerns). Using this pattern, user requests are routed to a Controller, which is responsible for working with the Model to perform user actions and/or retrieve results of queries. The Controller chooses the View to display to the user, and provides it with any Model data it requires.

The following diagram shows the three main components and which ones reference the others:

Expand All @@ -23,7 +23,7 @@ The following diagram shows the three main components and which ones reference t
This delineation of responsibilities helps you scale the application in terms of complexity because it's easier to code, debug, and test something (model, view, or controller) that has a single job. It's more difficult to update, test, and debug code that has dependencies spread across two or more of these three areas. For example, user interface logic tends to change more frequently than business logic. If presentation code and business logic are combined in a single object, an object containing business logic must be modified every time the user interface is changed. This often introduces errors and requires the retesting of business logic after every minimal user interface change.

> [!NOTE]
> Both the view and the controller depend on the model. However, the model depends on neither the view nor the controller. This is one of the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation.
> Both the view and the controller depend on the model. However, the model doesn't depend on the view or the controller. This is one of the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation.

### Model Responsibilities

Expand All @@ -39,7 +39,7 @@ Controllers are the components that handle user interaction, work with the model

> [!NOTE]
> Controllers shouldn't be overly complicated by too many responsibilities. To keep controller logic from becoming overly complex, push business logic out of the controller and into the domain model.

>
>[!TIP]
Copy link
Copy Markdown
Contributor

@wadepickett wadepickett Apr 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
>[!TIP]
> [!TIP]

Minor: space was missing.

> If you find that your controller actions frequently perform the same kinds of actions, move these common actions into [filters](#filters).

Expand Down Expand Up @@ -116,11 +116,11 @@ public async Task<IActionResult> Login(LoginViewModel model, string returnUrl =
}
```

The framework handles validating request data both on the client and on the server. Validation logic specified on model types is added to the rendered views as unobtrusive annotations and is enforced in the browser with [jQuery Validation](https://jqueryvalidation.org/).
The framework handles validating request data both on the client and on the server. Validation logic specified on model types is added to the rendered views as unobtrusive annotations and is enforced in the browser with [jQuery Validation](https://github.com/jquery-validation/jquery-validation).

## Dependency injection

ASP.NET Core has built-in support for [dependency injection (DI)](../fundamentals/dependency-injection.md). In ASP.NET Core MVC, [controllers](controllers/dependency-injection.md) can request needed services through their constructors, allowing them to follow the [Explicit Dependencies Principle](/dotnet/standard/modern-web-apps-azure-architecture/architectural-principles#explicit-dependencies).
ASP.NET Core has built-in support for [dependency injection (DI)](../fundamentals/dependency-injection.md). In ASP.NET Core MVC, [controllers](controllers/dependency-injection.md) can request needed services through their constructors, allowing them to follow the [Explicit Dependencies Principle](/dotnet/architecture/modern-web-apps-azure/architectural-principles#explicit-dependencies).

Your app can also use [dependency injection in view files](views/dependency-injection.md), using the `@inject` directive:

Expand Down Expand Up @@ -149,23 +149,23 @@ public class AccountController : Controller

## Areas

[Areas](controllers/areas.md) provide a way to partition a large ASP.NET Core MVC Web app into smaller functional groupings. An area is an MVC structure inside an application. In an MVC project, logical components like Model, Controller, and View are kept in different folders, and MVC uses naming conventions to create the relationship between these components. For a large app, it may be advantageous to partition the app into separate high level areas of functionality. For instance, an e-commerce app with multiple business units, such as checkout, billing, and search etc. Each of these units have their own logical component views, controllers, and models.
[Areas](controllers/areas.md) provide a way to partition a large ASP.NET Core MVC Web app into smaller functional groupings. An area is an MVC structure inside an application. In an MVC project, logical components like Model, Controller, and View are kept in different folders, and MVC uses naming conventions to create the relationship between these components. For a large app, it might be advantageous to partition the app into separate high level areas of functionality. For instance, an e-commerce app with multiple business units, such as checkout, billing, and search etc. Each of these units have their own logical component views, controllers, and models.

## Web APIs

In addition to being a great platform for building web sites, ASP.NET Core MVC has great support for building Web APIs. You can build services that reach a broad range of clients including browsers and mobile devices.

The framework includes support for HTTP content-negotiation with built-in support to [format data](xref:web-api/advanced/formatting) as JSON or XML. Write [custom formatters](xref:web-api/advanced/custom-formatters) to add support for your own formats.

Use link generation to enable support for hypermedia. Easily enable support for [Cross-Origin Resource Sharing (CORS)](https://www.w3.org/TR/cors/) so that your Web APIs can be shared across multiple Web applications.
Use link generation to enable support for hypermedia. Easily enable support for [Cross-Origin Resource Sharing (CORS)](https://fetch.spec.whatwg.org/#http-cors-protocol) so that your Web APIs can be shared across multiple Web applications.

## Testability

The framework's use of interfaces and dependency injection make it well-suited to unit testing, and the framework includes features (like a TestHost and InMemory provider for Entity Framework) that make [integration tests](xref:test/integration-tests) quick and easy as well. Learn more about [how to test controller logic](controllers/testing.md).

## Razor view engine

[ASP.NET Core MVC views](views/overview.md) use the [Razor view engine](views/razor.md) to render views. Razor is a compact, expressive and fluid template markup language for defining views using embedded C# code. Razor is used to dynamically generate web content on the server. You can cleanly mix server code with client side content and code.
[ASP.NET Core MVC views](views/overview.md) use the [Razor view engine](views/razor.md) to render views. Razor is a compact, expressive, and fluid template markup language for defining views using embedded C# code. Razor is used to dynamically generate web content on the server. You can cleanly mix server code with client side content and code.

```cshtml
<ul>
Expand Down
30 changes: 15 additions & 15 deletions aspnetcore/mvc/views/layout.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: Layout in ASP.NET Core
author: tdykstra
description: Learn how to use common layouts, share directives, and run common code before rendering views in an ASP.NET Core app.
ms.author: tdykstra
ms.date: 07/30/2019
ms.date: 04/29/2026
uid: mvc/views/layout
---
# Layout in ASP.NET Core
Expand All @@ -16,7 +16,7 @@ Pages and views frequently share visual and programmatic elements. This article
* Share directives.
* Run common code before rendering pages or views.

This document discusses layouts for the two different approaches to ASP.NET Core MVC: Razor Pages and controllers with views. For this topic, the differences are minimal:
This document discusses layouts for the two different approaches to ASP.NET Core MVC: Razor Pages and controllers with views. For this article, the differences are minimal:

* Razor Pages are in the *Pages* folder.
* Controllers with views uses a *Views* folder for views.
Expand All @@ -27,7 +27,7 @@ Most web apps have a common layout that provides the user with a consistent expe

![Page Layout example](layout/_static/page-layout.png)

Common HTML structures such as scripts and stylesheets are also frequently used by many pages within an app. All of these shared elements may be defined in a *layout* file, which can then be referenced by any view used within the app. Layouts reduce duplicate code in views.
Common HTML structures such as scripts and stylesheets are also frequently used by many pages within an app. All of these shared elements might be defined in a *layout* file, which any view used within the app can then reference. Layouts reduce duplicate code in views.

By convention, the default layout for an ASP.NET Core app is named `_Layout.cshtml`. The layout files for new ASP.NET Core projects created with the templates are:

Expand Down Expand Up @@ -87,13 +87,13 @@ The following markup uses the [Partial Tag Helper](xref:mvc/views/tag-helpers/bu
}
```

The preceding markup was generated by [scaffolding Identity](xref:security/authentication/scaffold-identity).
[Scaffolding Identity](xref:security/authentication/scaffold-identity) generated the preceding markup.

Sections defined in a page or view are available only in its immediate layout page. They cannot be referenced from partials, view components, or other parts of the view system.
Sections defined in a page or view are available only in its immediate layout page. They can't be referenced from partials, view components, or other parts of the view system.

### Ignoring sections

By default, the body and all sections in a content page must all be rendered by the layout page. The Razor view engine enforces this by tracking whether the body and each section have been rendered.
By default, the layout page must render the body and all sections in a content page. The Razor view engine enforces this by tracking whether the body and each section have been rendered.

To instruct the view engine to ignore the body or sections, call the `IgnoreBody` and `IgnoreSection` methods.

Expand All @@ -103,7 +103,7 @@ The body and every section in a Razor page must be either rendered or ignored.

## Importing Shared Directives

Views and pages can use Razor directives to import namespaces and use [dependency injection](dependency-injection.md). Directives shared by many views may be specified in a common `_ViewImports.cshtml` file. The `_ViewImports` file supports the following directives:
Views and pages can use Razor directives to import namespaces and use [dependency injection](dependency-injection.md). Directives shared by many views might be specified in a common `_ViewImports.cshtml` file. The `_ViewImports` file supports the following directives:

* `@addTagHelper`
* `@removeTagHelper`
Expand All @@ -120,7 +120,7 @@ A sample `_ViewImports.cshtml` file:

[!code-cshtml[](../../common/samples/WebApplication1/Views/_ViewImports.cshtml)]

The `_ViewImports.cshtml` file for an ASP.NET Core MVC app is typically placed in the *Pages* (or *Views*) folder. A `_ViewImports.cshtml` file can be placed within any folder, in which case it will only be applied to pages or views within that folder and its subfolders. `_ViewImports` files are processed starting at the root level and then for each folder leading up to the location of the page or view itself. `_ViewImports` settings specified at the root level may be overridden at the folder level.
The `_ViewImports.cshtml` file for an ASP.NET Core MVC app is typically placed in the *Pages* (or *Views*) folder. A `_ViewImports.cshtml` file can be placed within any folder, in which case it will only be applied to pages or views within that folder and its subfolders. `_ViewImports` files are processed starting at the root level and then for each folder leading up to the location of the page or view itself. `_ViewImports` settings specified at the root level might be overridden at the folder level.

For example, suppose:

Expand All @@ -131,12 +131,12 @@ Pages and views in the subfolder will have access to both Tag Helpers and the `M

If multiple `_ViewImports.cshtml` files are found in the file hierarchy, the combined behavior of the directives are:

* `@addTagHelper`, `@removeTagHelper`: all run, in order
* `@tagHelperPrefix`: the closest one to the view overrides any others
* `@model`: the closest one to the view overrides any others
* `@inherits`: the closest one to the view overrides any others
* `@using`: all are included; duplicates are ignored
* `@inject`: for each property, the closest one to the view overrides any others with the same property name
* `@addTagHelper`, `@removeTagHelper`: All run, in order.
* `@tagHelperPrefix`: The closest one to the view overrides any others.
* `@model`: The closest one to the view overrides any others.
* `@inherits`: The closest one to the view overrides any others.
* `@using`: All are included; duplicates are ignored.
* `@inject`: For each property, the closest one to the view overrides any others with the same property name.

<a name="viewstart"></a>

Expand All @@ -148,6 +148,6 @@ A sample `_ViewStart.cshtml` file:

[!code-cshtml[](../../common/samples/WebApplication1/Views/_ViewStart.cshtml)]

The file above specifies that all views will use the `_Layout.cshtml` layout.
The preceding file specifies that all views will use the `_Layout.cshtml` layout.

`_ViewStart.cshtml` and `_ViewImports.cshtml` are **not** typically placed in the */Pages/Shared* (or */Views/Shared*) folder. The app-level versions of these files should be placed directly in the */Pages* (or */Views*) folder.
Loading
Loading