ASP.NET MVC interview questions and answers

How It Works

A request is processed in a well-defined pipeline:

1. Routing: The URL is matched against endpoint routes configured in Program.cs (e.g. {controller=Home}/{action=Index}/{id?}).

2. Controller and action selection: The framework instantiates the matching controller (resolved from the DI container) and selects the action method.

3. Model binding: Request data (form fields, query string, route values, JSON body) is mapped to action parameters or a view model.

4. Model validation: Data annotations and other validators run; with [ApiController], an invalid model produces an automatic 400 Bad Request, otherwise you check ModelState.IsValid.

5. Filters: Authorization, resource, action, exception and result filters run in that order, wrapping cross-cutting concerns.

6. Action result: The action returns an IActionResult such as View, RedirectToAction, Json, or File.

7. View rendering: For a ViewResult, the Razor view (.cshtml) is located, rendered with the model, and written to the response.

Key Features

• Separation of concerns: Controllers, views and models can evolve and be tested independently.

• Testability: Controllers are plain classes that take dependencies through constructor injection, so unit tests can supply mock services and assert action results without a web server.

• Control over markup: Views are Razor templates where you write HTML directly with Tag Helpers; there are no hidden server-control abstractions emitting markup.

• Convention over configuration: The {Controller}/{Action} URL convention and view discovery (Views/ControllerName/ActionName.cshtml) reduce boilerplate.

• Extensible pipeline: Middleware, filters, model binders, value providers and routing endpoints can all be replaced or extended.

ASP.NET Core MVC vs WebForms

Advantages and Limitations

• Advantages: Clean separation of concerns, excellent unit-testability, precise control over HTML and HTTP, SEO-friendly URLs, and full access to the modern ASP.NET Core stack (dependency injection, middleware, minimal APIs, Blazor, SignalR).

• Limitations: More manual work than drag-and-drop server controls for data-heavy admin UIs — you build grids and forms explicitly, and you must manage state across postbacks yourself.

When to Choose What

Use ASP.NET Core MVC for new server-rendered web applications on .NET 8; it is the supported, cross-platform path. WebForms is a legacy technology: it runs only on .NET Framework 4.8, has no migration path to .NET Core or .NET 8, and Microsoft recommends ASP.NET Core MVC, Razor Pages or Blazor for new projects. Existing WebForms apps are typically kept on .NET Framework 4.8 or rewritten incrementally.

Note on Classic MVC 5

The MVC pattern also exists in classic ASP.NET MVC 5 on .NET Framework 4.8, but its plumbing differs: routing and filters are registered statically in RouteConfig.cs and FilterConfig.cs through Global.asax, whereas ASP.NET Core configures everything in Program.cs with built-in dependency injection and endpoint routing.

The Three Components

• Model: Represents the domain — entities, data transfer objects, business rules and validation logic. In ASP.NET Core MVC, models are plain C# classes, often decorated with data-annotation attributes such as [Required] or [Range] to express validation rules. Models should not know anything about HTTP, HTML or the database session; they are persistence- and UI-agnostic.

• View: Responsible only for presenting data to the user. In ASP.NET Core MVC, views are Razor files (.cshtml) that render HTML using data passed from the controller, typically a strongly typed view model plus Tag Helpers for forms and links. Views should contain no business or data-access logic.

• Controller: A class deriving from Controller whose public methods are actions. It parses the request, calls services and repositories to load or update models, and returns an action result (a view, a redirect, JSON, a file, or a status code). Controllers should stay thin: orchestration belongs here, heavy logic belongs in services.

How a Request Flows Through the Pipeline

1. Routing: The incoming URL is matched against endpoint routes configured in Program.cs (for example, MapControllerRoute with the {controller=Home}/{action=Index}/{id?} template). Classic ASP.NET MVC 5 instead defines routes statically in RouteConfig under App_Start and Global.asax.

2. Controller and action selection: The framework uses route values to pick the controller class and the action method, honoring constraints and HTTP verb attributes such as [HttpGet] or [HttpPost].

3. Model binding: Request data — form fields, query strings, route values, or JSON bodies — is mapped onto action parameters or a view model, with automatic type conversion and culture-aware parsing.

4. Model validation: Data-annotation and model-level validators populate ModelState; the action checks ModelState.IsValid before proceeding (with [ApiController], an invalid model automatically produces a 400 Bad Request with problem-details output).

5. Filters: Cross-cutting concerns run in a defined order — authorization filters, resource filters, action filters, exception filters, and result filters — both before and after the relevant stage.

6. Action execution: The action body runs and produces an action result.

7. Result execution and view rendering: If the result is a view, the framework locates the Razor view, passes the model to it, renders HTML, and writes the response; other results (redirects, JsonResult, FileResult) execute their own logic instead.

Benefits and Trade-offs

• Testability: Controllers and models can be unit tested in isolation from the UI, and views are passive.

• Parallel development: Teams can work on markup and domain logic simultaneously, communicating through view models.

• Control over HTML: Unlike Web Forms-style abstraction, MVC gives full control over the rendered output.

• Trade-offs: More moving parts than a simple page-oriented model, and it does not by itself prescribe how data is fetched or how the UI is composed — patterns such as repositories, view models, and dependency injection fill those gaps.

Best Practices

• Keep controllers thin and push logic into injected services registered in Program.cs.

• Never bind entity classes directly from user input; use dedicated view models (or [Bind]) to prevent over-posting.

• Validate early with data annotations and explicit ModelState.IsValid checks.

• Keep views free of data access; pass them only the data they need.

Request Flow in Component Order

1. Middleware pipeline — Every request passes through middleware (authentication, static files, exception handling, endpoint routing). MVC is added with builder.Services.AddControllersWithViews() and selected by the app.MapControllerRoute endpoints.

2. Routing — Matches the URL to a controller and action. ASP.NET Core uses endpoint routing, so the route is resolved early in the pipeline and the selected endpoint metadata drives later behavior. In classic MVC 5, routes are registered once in RouteConfig.RegisterRoutes inside Global.asax application startup instead.

3. Controller and action selection — The framework instantiates the controller (created by the DI container, so its constructor dependencies are injected) and picks the action method by name and HTTP verb constraints.

4. Model binding — Maps request data (route values, query string, form fields, JSON body) to the action’s parameters or to a view model.

5. Model validation — Runs data-annotation validators and other validators, storing results in ModelState. With [ApiController], an invalid model short-circuits the request with an automatic 400 Bad Request.

6. Filters — Cross-cutting concerns run in a defined pipeline: authorization filters first, then resource, action, exception, and finally result filters. Classic MVC 5 instead has authentication, authorization, action, result and exception filters, with no separate resource filter stage.

7. Action result — The action returns an IActionResult (a view, a redirect, JSON, a file, or a status code), which is executed to produce the response.

8. View rendering — For view results, the Razor engine finds the view, combines it with the view model, and writes the HTML to the response.

Key Components in Detail

• Controllers: Classes derived from Controller (or plain POCO classes) that expose action methods. They orchestrate work between the model and the view and should stay thin, delegating business logic to injected services.

• Models and view models: Data shapes passed between layers. Best practice is to bind user input to dedicated view models rather than directly to entity classes, which prevents over-posting.

• Views: Razor files (.cshtml) that render the response. ASP.NET Core prefers Tag Helpers for generating forms and links; HTML helpers such as Html.BeginForm are the older style still supported.

• View components: Self-contained rendering units, invoked from a view with @await Component.InvokeAsync(...). They replace classic MVC 5 child actions (Html.Action), which do not exist in ASP.NET Core.

• Filters: Attributes or classes implementing interfaces such as IAuthorizationFilter, IResourceFilter, IActionFilter, IExceptionFilter, and IResultFilter, used for logging, caching, validation, and error handling.

• Dependency injection: Built into ASP.NET Core; controllers, views, filters, and view components all resolve services from the application service provider.

Data Passing Between Actions and Views

Best Practices

• Keep controllers thin and put business logic in injected services registered in Program.cs.

• Always validate input with data annotations and check ModelState.IsValid in non-API actions.

• Protect forms with the antiforgery token: the form Tag Helper emits it automatically, and [ValidateAntiForgeryToken] or AutoValidateAntiforgeryTokenAttribute verifies it.

• Use strongly typed views with a view model instead of ViewData/ViewBag wherever practical.

Core Responsibilities and Pipeline Position

The request flow begins with routing, followed by controller and action selection, then model binding, model validation, filters, action result execution, and finally view rendering. The Controller sits at the center of this flow: after routing selects it, its action method runs business logic and returns an IActionResult that produces the response. The filter pipeline executes in a specific order: authorization, resource, action, exception, and result filters. Authorization ensures the user is permitted, while result filters can modify the output before it is sent. In classic MVC 5 on .NET Framework 4.8, filters were registered globally in FilterConfig.cs rather than via dependency injection or attributes, and the filter types were authentication, authorization, action, result and exception filters.

Data Handling and Validation

Model binding maps HTTP data to action parameters, followed by model validation using data annotations. You should check ModelState.IsValid manually unless using [ApiController], which automatically returns a 400 status code for invalid models. To pass data to views, use ViewData (a dictionary) or ViewBag (dynamic) for single-request data, and TempData for data surviving one redirect, which is cleared once read. Always use view models to prevent over-posting instead of binding entity classes directly, ensuring users cannot submit fields that do not belong to the form.

Selecting the Response

An action returns an IActionResult (or Task<IActionResult> for asynchronous actions), which keeps the controller decoupled from how the response is generated. Common results include ViewResult (renders a Razor view), RedirectToActionResult, ContentResult, JsonResult, FileResult and StatusCodeResult; Controller also provides helper methods such as View(), RedirectToAction(), Json() and File() to build them. This lets the same action logic serve a browser view, a JSON API response or a file download with a different return value.

Security Best Practices

Protect forms against CSRF attacks by ensuring the form tag helper includes the antiforgery token and applying [ValidateAntiForgeryToken] to POST actions, or enabling AutoValidateAntiforgeryToken globally. Never expose entity classes directly to user input; use specific view models or the [Bind] attribute to whitelist allowed properties, so users cannot manipulate fields they should not access, such as setting an IsAdmin flag. Tag Helpers are preferred in ASP.NET Core views over older HTML helpers like Html.BeginForm, and child actions (Html.Action) from MVC 5 are replaced by view components.

Common Pitfalls

• Over-posting: binding a domain entity directly lets a client set properties the form never exposed; always bind a view model.

• Business logic leakage: keep data access and domain rules in services injected through the constructor, so the controller stays focused on orchestration and HTTP concerns.

• Blocking async calls: use async/await and return Task<IActionResult> when calling databases or HTTP APIs, so thread-pool threads are not blocked.

• TempData misuse: TempData survives exactly one redirect and is removed once read, so it is not a substitute for a view model or a cache.

How It Works

Razor files use the .cshtml extension and allow developers to embed C# code within HTML using the @ symbol. During runtime or pre-compilation, the engine converts these files into C# classes that inherit from RazorPage. When a controller returns a ViewResult, the engine executes the generated class, merging the model data with the markup to produce the final HTML stream sent to the browser. This compilation process ensures type safety and IntelliSense support in editors like Visual Studio or VS Code.

Position in the Request Flow

Understanding where Razor fits clarifies its responsibility. The ASP.NET Core request pipeline proceeds through routing, controller and action selection, model binding, model validation, filters, and action result execution. Razor operates during the final view rendering phase, triggered when an action returns a ViewResult or PartialViewResult. It does not participate in routing or binding; its sole purpose is transforming the action’s data model into a representation suitable for the client.

Key Features and Components

• Layouts: Similar to master pages, _Layout.cshtml defines common structure (headers, footers) using @RenderBody() to inject specific view content.

• Tag Helpers: The modern approach for generating HTML elements. Unlike legacy HTML helpers (e.g., Html.BeginForm), Tag Helpers look like standard HTML attributes (e.g., <form asp-action="Login">), improving readability and maintainability.

• Partial Views: Reusable view fragments rendered via <partial> Tag Helper or Html.Partial, useful for breaking complex UIs into manageable components.

• View Components: Replace classic MVC 5 child actions, allowing logic-driven rendering of UI fragments independent of the main action.

Passing Data to Views

• ViewModels: Strongly typed classes passed to @model. This is the preferred method for preventing over-posting and ensuring compile-time checking.

• ViewData and ViewBag: Dynamic dictionaries (ViewData) or dynamic objects (ViewBag) that store data for a single request. They lack type safety and should be used sparingly.

• TempData: Stores data that survives one redirect, typically used for success or error messages. It is cleared once read, ensuring stale data does not persist across multiple requests.

Best Practices and Pitfalls

Always prefer strongly typed ViewModels over ViewBag to avoid runtime errors and facilitate refactoring. Keep business logic out of views; Razor should handle presentation only. When creating forms, rely on Tag Helpers to manage antiforgery tokens rather than manually writing hidden inputs. Avoid complex C# logic inside @{ } blocks, as this hinders testability and separates concerns poorly. Finally, ensure sensitive data is never exposed in the view model passed to the Razor engine.

Strongly-Typed View Models (Best Practice)

• View model: A dedicated class shaped for the view, passed as the action’s return model. This gives compile-time checking, IntelliSense, and enables model binding and validation.

• Over-posting protection: Never bind entity classes directly from user input; use a view model that exposes only the fields the form should allow the user to change.

• Validation: Decorate view-model properties with data annotations and check ModelState.IsValid in the POST action. With [ApiController], an invalid model returns 400 automatically, but regular MVC controllers require the explicit check.

ViewData and ViewBag

• ViewData: A ViewDataDictionary (string-keyed dictionary of objects). It lives only for the current request; it is not available after a redirect. Values require casting when read.

• ViewBag: A dynamic wrapper around ViewData. It has the same single-request lifetime but avoids casting because it uses dynamic.

• Use case: Suitable for small, view-specific metadata such as page titles, dropdown lists, or copyright text. Both are cleared at the end of the request.

TempData

• Lifetime: TempData survives one redirect (the next request) and is marked for deletion once read. This makes it ideal for status messages after a POST-Redirect-GET flow.

• Read behaviour: Reading a key removes it. Call TempData.Keep("Key") to preserve it for another request, or TempData.Peek("Key") to read without marking it for deletion.

• Storage: In ASP.NET Core the default provider stores TempData in cookies (with a size limit); it can be switched to session storage via AddSessionStateTempDataProvider. Classic MVC 5 stored TempData in session by default.

Security and Common Pitfalls

• CSRF: Always protect POST forms with [ValidateAntiForgeryToken]; the form tag helper emits the hidden token automatically when you use <form asp-action> or <form asp-controller>.

• Null keys: Accessing a missing ViewData/TempData key returns null, not an exception; guard with a null check before use.

• TempData on refresh: Because TempData is cleared after reading, refreshing the page will not re-show the message; use Peek or Keep if you need it to persist longer.

• Avoid ViewBag for core data: Relying on ViewBag/ViewData for primary view data sacrifices compile-time safety and makes refactoring harder; reserve them for peripheral metadata.

• Classic MVC 5 note: The same three mechanisms exist in MVC 5 on .NET Framework 4.8 with identical lifetimes; the main difference is that ASP.NET Core uses Tag Helpers in views instead of HTML helpers like Html.BeginForm, and child actions (Html.Action) are replaced by view components.

Session State in ASP.NET Core

In ASP.NET Core, session is not enabled by default. You register it as a service and add the middleware to the pipeline:

• AddSession configures session options such as idle timeout and cookie settings

• UseSession enables session handling for incoming requests, and must appear in the pipeline before the MVC routing middleware

• Session requires an IDistributedCache implementation; AddDistributedMemoryCache is the development default

Session values are stored as byte arrays, so you use typed helpers like SetString, GetString, SetInt32 and GetInt32. The session cookie is named .AspNetCore.Session and is HttpOnly by default. Data loads lazily on first access to HttpContext.Session.

TempData for Post-Redirect-Get

TempData is designed for the Post-Redirect-Get pattern, where you pass a short message (such as a success notice) to the next request:

• By default it uses CookieTempDataProvider, storing data in an encrypted, signed cookie

• SessionStateTempDataProvider is available when payloads exceed cookie limits

• Data is marked for deletion after it is read; call TempData.Keep() or TempData.Peek() to retain it

Distributed Session for Scale

In-memory session does not share state between servers, so a web farm needs a distributed store:

Register AddStackExchangeRedisCache or AddDistributedSqlServerCache before AddSession, since session uses the registered IDistributedCache as its backing store.

Classic ASP.NET MVC 5 Session Modes

In classic MVC 5 on .NET Framework 4.8, session state is configured in web.config with modes InProc, StateServer, SQLServer, Custom and Off, and is always available without middleware registration. This differs from ASP.NET Core, where session is opt-in and pluggable through dependency injection.

Best Practices and Security

• Keep session payloads small; large objects increase memory and serialization cost

• Never store passwords or sensitive personal data in session or TempData

• Set options.Cookie.IsEssential = true if session must work before cookie consent (GDPR)

• Use HTTPS and set Cookie.SecurePolicy to Always so the session cookie is not intercepted

• Prefer view models over storing form state in session to avoid stale data

ViewData

ViewData is a ViewDataDictionary — a dictionary of string keys to object values that is available on both Controller and the Razor page (ViewData property). It is populated by the framework for model binding metadata and view rendering, and you can add your own entries to it.

• Lifetime: scoped to a single HTTP request. It is set during the action and read during view rendering; it is gone once the response is sent.

• Type safety: values are stored as object, so you must cast when reading: var name = (string)ViewData["Name"];. A typo in the key returns null rather than a compile error.

• Typical use: passing a title, a breadcrumb, a select-list, or other loose display data that belongs only with the view being rendered.

ViewBag

ViewBag is a dynamic wrapper around the same ViewDataDictionary. Setting ViewBag.Title = "Home" and reading ViewData["Title"] refer to the same entry, so they are interchangeable storage but not interchangeable access style.

• Lifetime: identical to ViewData — one request only.

• Type safety: no casting is needed (@ViewBag.Title), which makes views cleaner, but there is no compile-time checking and no IntelliSense for the property names.

• Typical use: the same scenarios as ViewData, preferred when you want concise, cast-free access in a Razor view.

TempData

TempData is a TempDataDictionary whose values are stored in session state (via the session-based ITempDataProvider) and therefore survive across requests. It is designed for the PRG (Post-Redirect-Get) pattern.

• Lifetime: values persist until they are read or until the session ends. Reading a key marks it for removal at the end of the request, so data survives exactly one redirect and is then cleared.

• Keep for later: TempData.Keep("Key") (or the parameterless TempData.Keep() for all keys) re-marks a key for retention so it survives a further request; TempData.Peek("Key") reads a value without marking it for deletion.

• Type safety: like ViewData, values are stored as object and must be cast on read.

• Typical use: a status message shown after a redirect, such as “Product created successfully”, or round-tripping an invalid model’s input from the POST action to the GET action that re-renders the form.

• Requirement: because it uses session, the session middleware must be configured in Program.cs (builder.Services.AddSession() and app.UseSession()), otherwise reading or writing TempData throws.

Choosing Between Them

Best Practices and Common Pitfalls

• Prefer a strongly typed view model over all three. A dedicated view model gives compile-time checking, IntelliSense and clean unit tests; use ViewData/ViewBag only for incidental data such as a page title that does not belong on the model.

• Do not use TempData as a general cache or a way to carry data through several screens. Its read-once semantics surprise people: a refresh after the redirect silently drops the message.

• Do not store large or sensitive objects in TempData. It is stored in session state (server-side or distributed cache), so keep it small and avoid secrets.

• Remember the session middleware order. app.UseSession() must be called before app.MapControllerRoute() (or any MVC middleware that reads TempData) in the pipeline.

• In classic ASP.NET MVC 5 the same three exist with the same lifetimes; the main differences are that session is enabled by default in the pipeline and that TempData uses the SessionStateTempDataProvider, whereas ASP.NET Core requires you to opt into session explicitly.

What They Are and How They Work

An HTML Helper is a method that returns an HTML string. When a view is rendered, the helper runs on the server, builds the markup and writes it into the response. Because the output is generated from model values and expression trees, helpers keep views concise and reduce repeated markup.

• Built-in helpers: shipped with the framework for common elements such as text boxes, labels, dropdowns, checkboxes, links and forms.

• Strongly-typed helpers: helpers ending in For (for example TextBoxFor) accept a lambda expression pointing at a model property, so the name, id and value attributes are inferred automatically and compile-time checking is available.

• Custom helpers: you can write your own as extension methods on IHtmlHelper (or HtmlHelper in MVC 5) and call them the same way.

Common Built-in Helpers

HTML Helpers vs Tag Helpers

Tag Helpers are the newer, preferred way to build server-side HTML in ASP.NET Core views. They let you write standard HTML elements with extra attributes (for example <input asp-for="Name">), which is more readable and works better with client-side tooling.

In classic ASP.NET MVC 5, Tag Helpers do not exist, so HTML Helpers are the only option; MVC 5 also supports child actions via Html.Action, which do not exist in ASP.NET Core and are replaced by view components.

Security Behaviour

HTML Helpers encode output by default, which prevents cross-site scripting (XSS) when rendering user-supplied values. For forms, combine Html.BeginForm with Html.AntiForgeryToken and decorate the POST action with [ValidateAntiForgeryToken] to protect against CSRF.

Code Example

The following view uses strongly-typed helpers inside a POST form; the controller action checks model validity and the antiforgery token.

@model ProductViewModel

<h2>Create Product</h2>

@using (Html.BeginForm("Create", "Products", FormMethod.Post))
{
    @Html.AntiForgeryToken()

    <div>
        @Html.LabelFor(m => m.Name)
        @Html.TextBoxFor(m => m.Name)
        @Html.ValidationMessageFor(m => m.Name)
    </div>

    <div>
        @Html.LabelFor(m => m.Price)
        @Html.TextBoxFor(m => m.Price)
        @Html.ValidationMessageFor(m => m.Price)
    </div>

    <button type="submit">Create</button>
}

using System.ComponentModel.DataAnnotations;

public class ProductViewModel
{
    [Required]
    [StringLength(100)]
    public string Name { get; set; }

    [Required]
    [Range(0.01, 10000.00)]
    public decimal Price { get; set; }
}

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Create(ProductViewModel model)
{
    if (!ModelState.IsValid)
    {
        return View(model);
    }

    // Save the validated model.
    return RedirectToAction(nameof(Index));
}

Best Practices and Common Pitfalls

• Prefer Tag Helpers in new ASP.NET Core projects; use HTML Helpers when maintaining existing views or when a helper has no Tag Helper equivalent.

• Use strongly-typed For helpers instead of string-based ones so property names are checked at compile time and refactoring is safe.

• Never bind entity classes directly to form helpers; use a view model to prevent over-posting.

• Check ModelState.IsValid in the POST action before processing input.

• Avoid ViewBag/ViewData for form data; pass data through the model or a view model.

• Remember TempData semantics: ViewData and ViewBag live for one request, while TempData survives one redirect and is cleared once read.

How It Works

The framework uses value providers to read data from the request and match it to parameter names or property names by case-insensitive comparison. For complex types, it recursively binds public settable properties and collections. In the request flow, this happens after controller and action selection and before model validation and filters. In classic MVC 5 on .NET Framework 4.8, the process is similar, but custom binders are registered through ModelBinders.Binders or ModelBinderProviders.BinderProviders in Application_Start rather than through the ASP.NET Core dependency injection system.

Value Providers and Data Sources

• Form values: Posted form fields, checked first for simple types without a source attribute.

• Route values: Parameters extracted from the URL path by the routing system.

• Query string: Values appended after the ? in the URL.

• Request body: JSON or XML payloads, used with [FromBody].

The default binding source order for simple types is form fields, then route values, then the query string. You can restrict the source explicitly using binding attributes.

Binding Attributes

• [FromQuery]: Binds from the URL query string.

• [FromRoute]: Binds from route data.

• [FromForm]: Binds from posted form fields.

• [FromBody]: Binds from the request body, typically JSON in APIs.

• [BindPrefix]: Limits binding to properties under a specified prefix.

Simple types like int or string are optional parameters by default, while complex types are required unless marked nullable.

Validation Integration

Model binding feeds into model validation. Data annotation attributes like [Required] or [EmailAddress] on your model properties are evaluated after binding, during the model validation phase. Errors are added to the ModelState dictionary, which you must check using ModelState.IsValid. Note that actions decorated with [ApiController] automatically return a 400 Bad Request if the model is invalid, whereas standard MVC controllers require an explicit check.

Security and Best Practices

• Prevent over-posting: Always bind to a dedicated view model instead of an entity class, or use [Bind] to whitelist properties.

• Protect against CSRF: The form tag helper includes the antiforgery token, and [ValidateAntiForgeryToken] verifies it on the server.

• Avoid binding primitives blindly: Use specific attributes like [FromQuery] to clarify where data originates, reducing ambiguity.

• Common pitfall: Forgetting that ModelState.IsValid must be checked manually in non-API controllers, otherwise invalid data may be processed.

• Collections and arrays: Model binding handles List<T> and arrays automatically when form field names use index notation (for example Items[0].Name).

Execution Context within Request Flow

During the standard request flow, routing selects the controller and action, followed by model binding, validation, and filter execution. Once the action returns a view result, the view rendering phase begins, which is where _ViewStart.cshtml intervenes. It executes before the specific view content is processed, allowing it to configure environment settings like the master layout page before any HTML is generated.

Layout Inheritance and Folder Hierarchy

The file follows a hierarchical inheritance model based on folder structure. The Razor engine searches for _ViewStart.cshtml in the view’s directory and continues up to the root Views folder. A definition in Views/_ViewStart.cshtml applies globally, whereas one in Views/Product/_ViewStart.cshtml overrides the global setting only for product views. This enables different sections of an application to utilize distinct layouts without hardcoding paths in every view. Developers can set Layout = null here to disable layouts for specific folders.

Distinction from _ViewImports.cshtml

Developers often confuse _ViewStart.cshtml with _ViewImports.cshtml, but their roles differ significantly. The imports file handles namespace declarations and Tag Helper registration, such as enabling asp-action and asp-controller attributes across all views. Conversely, _ViewStart contains executable C# code and property assignments. Registering Tag Helpers inside _ViewStart will fail, just as assigning layouts inside _ViewImports has no effect. Always ensure Tag Helpers are imported correctly to maintain secure form generation.

Comparison with Classic ASP.NET MVC 5

In classic ASP.NET MVC 5 on .NET Framework 4.8, _ViewStart.cshtml functions identically regarding layout assignment and execution order. The distinction arises in project configuration; ASP.NET Core relies on built-in dependency injection and middleware pipelines, whereas MVC 5 uses Global.asax and BundleConfig for similar setup tasks. Despite these infrastructure differences, the Razor view engine’s handling of the start file remains consistent between versions.

Best Practices

Keep logic minimal to avoid performance overhead during view rendering. Never place business logic or database access here, as it runs for every view request. Use view models for data passing instead of relying heavily on ViewBag modifications within this file. Ensure Layout paths are correct to prevent runtime exceptions when rendering views. Avoid storing sensitive configuration values in this file as it is part of the view layer.

Partial Views

• A Partial View is a Razor file, conventionally prefixed with an underscore (e.g. _LoginPartial.cshtml), containing markup that is reused across multiple views.

• It is rendered using the <partial> Tag Helper or the @await Html.PartialAsync HTML helper (the older style).

• Because it runs within the parent pipeline, it shares the same ViewData, ViewBag, and TempData. ViewData and ViewBag live for one request; TempData survives one redirect and is cleared once read.

• Ideal for static or simple dynamic content such as headers, footers, navigation bars, and form field groups.

View Components

• A View Component is a class that inherits from ViewComponent and exposes an InvokeAsync method to prepare its own model.

• It is invoked from a view using @await Component.InvokeAsync("Name", args).

• Unlike Partial Views, it has its own lifecycle, supports constructor dependency injection, and does not share the parent view data.

• View Components are the ASP.NET Core replacement for classic MVC 5 child actions ([ChildActionOnly] with Html.Action), which do not exist in ASP.NET Core.

Key Differences

Best Practices and Pitfalls

• Use Partial Views for markup reuse: If you are just splitting a large view into smaller files without adding logic, a Partial View is simpler.

• Use View Components for logic: If the fragment needs to query a database, call an API, or assemble its own data (like a shopping cart badge or recent posts list), use a View Component.

• Avoid heavy logic in Partials: Putting business logic inside a Partial View makes it hard to test and violates separation of concerns.

• Mind the view path: View Component views must live in Views/<Controller>/Components/<Name>/Default.cshtml or Views/Shared/Components/<Name>/Default.cshtml.

• Keep components stateless: Do not store request-specific state in the component class instance.

How It Works

Attribute routes are discovered when the app starts, as part of MVC framework initialization, and are registered as endpoints by endpoint routing. You opt in by calling MapControllers() (an extension on IEndpointRouteBuilder):

1. A request arrives and endpoint routing matches the request path and HTTP method against all registered endpoints.

2. The matching route template supplies route values (controller, action, and any parameters such as id).

3. Controller and action selection uses those route values to pick the action method.

4. Model binding, model validation, filters, and action-result execution then run as they would with any other route.

A template placed on the controller is a prefix for every action in it, unless the action template starts with / or ~/, which makes it absolute. Route names can be referenced for URL generation with Url.ActionLink, RedirectToRoute, or LinkGenerator.

Key Features

• Inline templates: [Route("products/{id:int}")] declares the pattern and the parameter in one place, next to the code it belongs to.

• HTTP verb attributes: [HttpGet], [HttpPost], [HttpPut], [HttpPatch], and [HttpDelete] constrain the method and can also carry a template, so multiple actions with the same action name can coexist.

• Token replacement: [controller], [action], and [area] in a template are replaced at startup, e.g. [Route("api/[controller]")] on ProductsController becomes api/Products.

• Optional and default values: {id?} makes a segment optional; {id:int?} makes it optional and constrained.

• Route constraints: {id:int}, {id:guid}, {slug:alpha:minlength(3)}, {page:int:range(1,100)} reject URLs that do not match, so the action is never even selected.

• Route names: [HttpGet("{id}", Name = "GetProduct")] lets you generate links without hard-coding the template.

• Areas: [Area("Admin")] on the controller plus [Route("[area]/[controller]/[action]")] gives area-aware URLs.

Attribute Routing vs Conventional Routing

Best Practices and Common Pitfalls

• Prefer attribute routing for APIs and conventional routing for view apps; mixing both is supported, but keep one clear primary style per area.

• Use [Route("api/[controller]")] rather than repeating the literal controller name, so renames stay consistent.

• Constrain route parameters ({id:int} instead of {id}) to avoid ambiguous matches and to reject malformed URLs early.

• Do not bind directly to entity classes from route or body input; use a view model or DTO to prevent over-posting.

• Two actions with the same verb and template produce an AmbiguousMatchException at request time; give each a distinct template or verb.

• In classic ASP.NET MVC 5 on .NET Framework 4.8, attribute routing is not automatic: you must enable it explicitly with routes.MapMvcAttributeRoutes() inside RouteConfig.cs in App_Start, and the attributes come from System.Web.Mvc rather than Microsoft.AspNetCore.Mvc.

How Forms Authentication Works

• The user submits credentials to a login action, which validates them against a user store (for example the legacy Membership provider or a custom repository).

• On success, the server creates an encrypted authentication ticket, writes it into a cookie with FormsAuthentication.SetAuthCookie, and redirects the user back to the originally requested URL.

• On each subsequent request, the Forms Authentication module decrypts the cookie, builds an IPrincipal, and populates HttpContext.User so [Authorize] can enforce access.

• On logout, FormsAuthentication.SignOut removes the cookie.

Configuration in web.config

• Set <authentication mode="Forms"> with a <forms> element specifying loginUrl, timeout (minutes), slidingExpiration, and requireSSL="true" when running over HTTPS.

• Use <authorization> with <deny users="?" /> to block anonymous users by default, then allow specific roles or users where needed.

• Configure the membership provider if you rely on the built-in user store, though most production apps use a custom store with proper password hashing (never plain text).

Code Example

public class AccountController : Controller
{
    // GET: /Account/Login
    public ActionResult Login(string returnUrl)
    {
        ViewBag.ReturnUrl = returnUrl;
        return View();
    }

    // POST: /Account/Login
    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult Login(LoginViewModel model, string returnUrl)
    {
        if (!ModelState.IsValid)
            return View(model);

        // Validate credentials against a secure user store with hashed passwords.
        if (UserService.ValidateUser(model.UserName, model.Password))
        {
            // Issue the Forms Authentication cookie; createPersistentCookie false = session cookie.
            FormsAuthentication.SetAuthCookie(model.UserName, createPersistentCookie: false);

            // Only redirect to a local URL to prevent open-redirect attacks.
            if (Url.IsLocalUrl(returnUrl))
                return Redirect(returnUrl);

            return RedirectToAction("Index", "Home");
        }

        ModelState.AddModelError("", "Invalid username or password.");
        return View(model);
    }

    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult Logout()
    {
        FormsAuthentication.SignOut();
        return RedirectToAction("Index", "Home");
    }
}

Protecting Controllers and Actions

• Apply [Authorize] at the controller level to require authentication for every action, or on individual actions for finer control.

• Use [Authorize(Roles = "Admin")] to restrict access to specific roles.

• Unauthenticated users are automatically redirected to the loginUrl defined in web.config.

ASP.NET Core Replacement

Forms Authentication does not exist in ASP.NET Core MVC. The supported approach is ASP.NET Core Identity with the cookie authentication middleware configured in Program.cs via AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) and AddCookie, with [Authorize] working the same way on controllers.

Common Pitfalls and Best Practices

• Always use HTTPS: set requireSSL="true" and mark the cookie as secure; otherwise credentials and session cookies can be intercepted.

• Never store plain-text passwords; use a strong hash (for example PBKDF2, bcrypt, or the Identity password hasher).

• Validate return URLs with Url.IsLocalUrl to prevent open-redirect attacks after login.

• Include [ValidateAntiForgeryToken] on POST actions; Forms Authentication protects identity, not CSRF.

• Do not use this for new development: Forms Authentication is deprecated; new ASP.NET Core projects should use ASP.NET Core Identity.

How It Works

ASP.NET Core implements the Synchronizer Token Pattern. When a page containing a form is rendered, the server generates a random token. This token is sent to the client in two places: - Hidden Input Field: Embedded inside the <form> element. - Cookie: Stored in the user’s browser as a non-HTTP-only cookie.

When the form is submitted via POST, the server compares the token from the form field against the token in the cookie. If they match, the request is legitimate. If they differ or are missing, the server rejects the request with a 400 Bad Request error. This works because malicious sites cannot read the cookie value due to same-origin policies, preventing them from constructing a valid request.

Code Example

In ASP.NET Core MVC, the Form Tag Helper automatically renders the antiforgery token, making explicit helper calls optional. Tag Helpers are the current recommended style; HTML helpers (Html.BeginForm, Html.AntiForgeryToken) are the older style.

@model MyViewModel
<form asp-action="Submit" method="post">
    <!-- Token automatically added by Form Tag Helper -->
    <input asp-for="Name" />
    <button type="submit">Submit</button>
</form>

The older HTML helper approach still works but is not the recommended style:

@using (Html.BeginForm("Submit", "Home", FormMethod.Post))
{
    @Html.AntiForgeryToken()
    <input name="Name" />
    <button type="submit">Submit</button>
}

On the controller side, apply the validation attribute to the action method:

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Submit(MyViewModel model)
{
    if (!ModelState.IsValid)
    {
        return View(model);
    }
    // Process data
    return RedirectToAction("Success");
}

Validation Flow

The ASP.NET Core MVC request lifecycle executes in this order: 1. Routing: Matches the URL to an endpoint. 2. Controller and Action Selection: The framework chooses the controller and action method. 3. Model Binding: Populates action parameters from request data. 4. Model Validation: Data annotations are checked and ModelState is populated. 5. Filters: Run in the order authorization, resource, action, exception, and result. Authorization filters execute first, before model binding. 6. Action Result: The action returns a result such as a view or redirect. 7. View Rendering: The response HTML is generated.

[ValidateAntiForgeryToken] implements IAuthorizationFilter, so it runs in the early authorization stage. If validation fails, the pipeline short-circuits and returns a 400 Bad Request without executing the action.

Best Practices

• Global Validation: Use [AutoValidateAntiforgeryToken] at the controller or global level to protect all POST actions by default, reducing the risk of missing attributes on new endpoints.

• HTTPS: Always serve forms over HTTPS to prevent token interception during transmission.

• View Models: Bind to view models rather than entity classes to prevent overposting, even though antiforgery protects against CSRF.

• AJAX Requests: When submitting forms via JavaScript, manually retrieve the token from the hidden field or cookie and include it in the request headers (e.g., RequestVerificationToken).

• Avoid Disabling: Do not disable antiforgery validation ([IgnoreAntiforgeryToken]) unless the endpoint is purely read-only or intended for public API consumption without cookies.

Note: In classic ASP.NET MVC 5 on .NET Framework 4.8, @Html.AntiForgeryToken() was mandatory inside forms and [ValidateAntiForgeryToken] was required on actions, as Tag Helpers did not exist to automate token injection.

Purpose and Structure

Areas help manage complexity as an application grows beyond a single set of controllers. - Folder Organization: Code is grouped under an Areas folder, such as Areas/Admin/Controllers and Areas/Shop/Controllers, keeping the root Controllers folder clean. - View Location Search: The view engine searches area-specific folders first, looking in Areas/{AreaName}/Views/{Controller} before falling back to Views/Shared. - Logical Isolation: Different areas often require different layouts, authorization policies, and business logic, allowing teams to work on modules independently.

Routing and Configuration

In ASP.NET Core MVC, areas are enabled through attributes and endpoint routing rather than registration classes. - Controller Attribute: The [Area("Admin")] attribute is applied directly to the controller class to assign it to a specific area. - Route Template: The Program.cs configuration must include a route pattern with the {area:exists} constraint so URLs like /Admin/Home/Index are matched correctly. - Link Generation: When generating links from outside an area, you must specify the asp-area attribute; links generated inside an area default to that current area unless overridden.

Difference in Classic MVC 5

Classic MVC 5 on .NET Framework 4.8 requires a dedicated AreaRegistration class with a RegisterArea method that calls context.MapRoute, and all areas must be registered via AreaRegistration.RegisterAllAreas() in Global.asax; ASP.NET Core replaces this convention with attributes and endpoint routing.

Code Example

// Program.cs - conventional route with area constraint
app.MapControllerRoute(
    name: "areas",
    pattern: "{area:exists}/{controller=Home}/{action=Index}/{id?}");

// Areas/Admin/Controllers/HomeController.cs
using Microsoft.AspNetCore.Mvc;

[Area("Admin")]
public class HomeController : Controller
{
    public IActionResult Index() => View();
}

<!-- Views/Shared/_Layout.cshtml -->
<a asp-area="Admin" asp-controller="Home" asp-action="Index">Admin Dashboard</a>

Best Practices

• Use for Large Apps: Only introduce areas when the controller count grows significantly; small applications do not need the added folder complexity.

• Consistent Naming: Match the area attribute name exactly to the folder structure to avoid routing mismatches and 404 errors.

• Shared Resources: Place shared layouts and navigation in Views/Shared so they remain accessible across all areas.

• Authorization: Apply authorization policies at the area level by placing a filter on a base controller that all area controllers inherit from.

Middleware and Global Handling

The request pipeline is where global error handling is configured. In development, UseDeveloperExceptionPage shows detailed exception, stack trace, and request information; in production it is replaced by UseExceptionHandler, which catches unhandled exceptions and re-executes the pipeline at a path such as /Home/Error, where a controller returns a friendly view or a JSON error object. Exception-handling middleware should be placed early in the pipeline, before middleware whose exceptions it needs to catch. For HTTP errors that are not exceptions (for example, a 404 for an unknown URL), UseStatusCodePages or UseStatusCodePagesWithReExecute adds simple status-code handling or re-executes a controller action for a branded error page.

Exception Filters and Order

For finer control inside the MVC pipeline, implement IExceptionFilter (or IAsyncExceptionFilter) and register it globally, on a controller, or on an action. MVC runs its filters in a fixed order: authorization, resource, action, exception, and result. Exception filters therefore only see exceptions raised during action execution or later stages — not exceptions thrown earlier in the middleware pipeline, which is why middleware-level handling is still needed. An exception filter can log the error and set context.Result to a specific response, such as a custom view or a JSON error object, based on the exception type.

Model Validation Errors

Validation failures are handled separately from runtime exceptions. Models use data annotations such as [Required] and [StringLength] to declare rules; in an action you check ModelState.IsValid and, when it is false, return the view with the model so validation messages render. On controllers decorated with [ApiController], an invalid model automatically returns a 400 Bad Request response with problem details, without manual checks.

Classic MVC 5 Differences

In classic ASP.NET MVC 5 on .NET Framework 4.8, error handling relies on the HandleErrorAttribute and the customErrors section in web.config, and global handling is often done in Application_Error in Global.asax. ASP.NET Core replaces Global.asax and customErrors with middleware, and replaces HandleErrorAttribute with the filter and middleware model described above.

Best Practices

• Hide details in production: return only a generic message to clients; log stack traces and request details server-side.

• Use view models: bind user input to view models rather than entity classes to prevent over-posting, including on error-recovery paths.

• Keep CSRF protection: error pages that render forms still need the antiforgery token, validated with [ValidateAntiForgeryToken].

• Prefer Tag Helpers: build error-page forms with Tag Helpers; HTML helpers such as Html.BeginForm are the older style.

• Carry messages with TempData: for error messages that must survive a redirect, remember TempData survives one redirect and is cleared once read.

What Dependency Injection Solves

Without DI, a controller that needs data access creates its own dependency, for example new ProductRepository(). That couples the controller to one concrete implementation, makes unit testing difficult, and duplicates lifetime management. DI inverts this: the class declares what it needs (IProductRepository), and the framework supplies an instance at runtime. The main benefits are loose coupling, easier unit testing with mock or fake dependencies, centralised lifetime control, and consistent configuration across the application.

Built-in DI in ASP.NET Core MVC

ASP.NET Core ships with a minimal but sufficient container. You register abstractions and their implementations in Program.cs using builder.Services, and the container resolves dependencies automatically when it creates controllers, view components, filters, middleware, or hosted services. Third-party containers (Scrutor, Autofac, Lamar) can replace the built-in one through IServiceProviderFactory when you need advanced features such as assembly scanning, property injection, or convention-based registration.

Service Lifetimes

Choose a lifetime that matches how much state the service holds and how widely it is shared:

A singleton must not depend on a scoped service. By default ASP.NET Core validates scopes when the app runs in the Development environment and throws when a singleton is resolved with a scoped dependency; with validation disabled the scoped instance is captured and outlives its request. If a singleton needs scoped data, inject IServiceScopeFactory and create a scope explicitly.

Registering and Consuming Services

• Register by interface: services.AddScoped<IProductRepository, ProductRepository>() so consumers depend on the abstraction.

• Constructor injection is the default and preferred way for controllers and services.

• [FromServices] injects a service into a single action method parameter when only one action needs it.

• @inject in a .cshtml view pulls a service into a view; use it sparingly, mainly for view-specific concerns such as a menu service.

• ServiceFilterAttribute is the way to apply an MVC filter whose dependencies must be resolved by the container.

Code Example

// Program.cs — register services before building the app
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();

// Abstraction mapped to implementation with a scoped lifetime
builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddSingleton<ICatalogCache, CatalogCache>();

var app = builder.Build();

app.UseStaticFiles();
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

// Minimal types the example relies on
public sealed class Product
{
    public int Id { get; init; }
    public string Name { get; init; } = string.Empty;
}

public sealed class ProductsDbContext : DbContext
{
    public DbSet<Product> Products => Set<Product>();
}

// Interface defines the contract consumers depend on
public interface IProductRepository
{
    Task<IReadOnlyList<Product>> GetAllAsync(CancellationToken ct);
}

// Implementation knows nothing about which controller uses it
public sealed class ProductRepository : IProductRepository
{
    private readonly ProductsDbContext _db;

    // The DbContext is itself resolved from the container
    public ProductRepository(ProductsDbContext db) => _db = db;

    public Task<IReadOnlyList<Product>> GetAllAsync(CancellationToken ct) =>
        _db.Products.AsNoTracking().ToListAsync(ct);
}

// Controller declares dependencies; the framework supplies them
public sealed class ProductsController : Controller
{
    private readonly IProductRepository _products;

    public ProductsController(IProductRepository products) => _products = products;

    public async Task<IActionResult> Index(CancellationToken ct)
    {
        var model = await _products.GetAllAsync(ct);
        return View(model);
    }
}

@* Optional: inject a service directly into a view *@
@inject ICatalogCache CatalogCache

Best Practices and Pitfalls

• Depend on interfaces, not classes, so implementations can be swapped and tests can supply fakes.

• Keep the composition root in Program.cs; do not resolve services with app.Services.GetService<T>() inside controllers or business code.

• Prefer constructor injection over service locator patterns, which hide dependencies and break compile-time analysis.

• Do not mix lifetimes carelessly: injecting a scoped service into a singleton throws when scope validation is enabled and otherwise silently captures state.

• In classic ASP.NET MVC 5 on .NET Framework 4.8, the framework has no built-in container: you install a library such as Unity, Ninject, or Autofac, configure it in Global.asax (Application_Start), and wire it through DependencyResolver.SetResolver(...); controllers then use the same constructor-injection style.

Role in the Request Pipeline

Understanding where filters fit is crucial for debugging and architecture. The ASP.NET Core request flow proceeds through routing, controller and action selection, model binding, and model validation before reaching the filter stage. Once validation passes, filters execute in a specific sequence. Action filters specifically wrap the action method execution. After the action runs, result filters execute before the view is rendered or the response is written. This positioning allows action filters to inspect ModelState before business logic runs or manipulate the result afterward. If an action filter sets context.Result, the action method is skipped entirely.

Filter Execution Order

ASP.NET Core defines five filter types that run in a strict order. Knowing this sequence prevents unexpected behavior when multiple filters apply to the same endpoint. - Authorization Filters: Run first to determine if the user is allowed to proceed based on policies or roles. - Resource Filters: Run before model binding and can short-circuit the pipeline, often used for caching. - Action Filters: Run immediately before and after the action method executes, allowing argument inspection. - Exception Filters: Handle unhandled exceptions thrown during previous stages, providing a centralized error handler. - Result Filters: Run before and after the action result executes, such as before a view is rendered.

Classic MVC 5 also uses filters but registers them differently via FilterConfig and lacks the resource filter type found in Core.

Creating and Registering Action Filters

• Create: Inherit from ActionFilterAttribute and override OnActionExecuting (runs before the action) and OnActionExecuted (runs after the action).

• Before the action: In OnActionExecuting, inspect context.ActionArguments and context.ModelState; setting context.Result skips the action method entirely.

• After the action: In OnActionExecuted, inspect or modify context.Result before it executes.

• Dependency injection: Constructor injection of services such as ILogger<T> is supported, but the filter must be registered as a service in Program.cs and added through options.Filters.Add<T>(); applying the filter as an attribute instantiates it directly without DI.

• Scope: Filters can be applied globally, per controller, or per action using attributes.

Best Practices and Common Pitfalls

• Keep Logic Lightweight: Avoid heavy database calls in action filters; use resource filters for caching instead to prevent blocking the pipeline.

• Check ModelState: While [ApiController] returns 400 automatically for invalid models, manual filters should verify ModelState.IsValid if custom handling is needed.

• Avoid Business Logic: Filters should handle cross-cutting concerns, not core business rules, to maintain testability and separation of concerns.

• Order Matters: When multiple filters exist, execution order depends on registration scope (global vs. attribute) and explicit ordering properties like Order.

• Security: Never log sensitive data such as passwords or tokens within filter logging logic.

Using action filters correctly ensures clean separation of concerns while maintaining control over the execution flow in ASP.NET Core MVC applications.

How the Flow Works

• The view renders normally, but form submissions or button clicks are intercepted by JavaScript.

• JavaScript builds a request with fetch or jQuery $.ajax, setting Content-Type: application/json.

• Routing selects the controller action, [FromBody] model-binds the JSON payload, validation runs, and the action returns JsonResult via the Json() helper.

• The client callback receives the JSON and updates the DOM.

Server-Side Setup

Actions return IActionResult and use Json() to serialize an object. For POST requests you must validate the antiforgery token, because AJAX does not automatically send the hidden form token. Register the header name in Program.cs:

builder.Services.AddAntiforgery(options => options.HeaderName = "RequestVerificationToken");

Decorate POST actions with [ValidateAntiForgeryToken] and check ModelState.IsValid. With [ApiController] an invalid model returns 400 automatically; plain controllers must check manually. Unlike classic MVC 5, Json() allows GET requests by default and there is no JsonRequestBehavior.AllowGet or HttpContext.Current.

Client-Side Calls

Read the token from the hidden field the form tag helper renders, then send it in the request header. Use fetch (built in, no library) or jQuery if the project already references it.

Code Example

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> SubmitOrder([FromBody] OrderViewModel model)
{
    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    var orderId = await _repository.SaveAsync(model);
    return Json(new { success = true, orderId });
}

<form asp-controller="Order" asp-action="SubmitOrder" method="post">
    <button type="button" id="submitBtn">Place Order</button>
</form>

<script>
document.getElementById('submitBtn').addEventListener('click', async () => {
    const token = document.querySelector('input[name="__RequestVerificationToken"]')?.value;
    const order = { productId: 5, quantity: 2 };

    const response = await fetch('/Order/SubmitOrder', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'RequestVerificationToken': token
        },
        body: JSON.stringify(order)
    });

    const result = await response.json();
    if (result.success) console.log('Order', result.orderId);
});
</script>

Security and Best Practices

• Prevent over-posting: bind a view model to [FromBody] parameters, never an entity class directly.

• CSRF protection: always send the antiforgery token on state-changing POST/PUT/DELETE requests; read-only GET calls do not need it.

• Validate input: check ModelState.IsValid and return BadRequest for failures so the client can display field errors.

• Error handling: wrap calls in try/catch on the client and return meaningful HTTP status codes (200, 400, 404, 500) from the server.

• Keep responses small: return only the data the client needs, not entire view models with navigation properties.

How It Works

The default model binder handles common formats like query strings, form fields, and JSON bodies automatically. When it runs, it looks for a binder that matches the parameter type. If you provide a custom implementation, it intercepts this process via the BindModelAsync method. Inside this method, you read raw values from bindingContext.ValueProvider, parse or transform them, and assign the final object to bindingContext.Result using ModelBindingResult.Success. If parsing fails, you call ModelBindingResult.Failed and add an error to bindingContext.ModelState so validation logic downstream catches it.

Common Use Cases

You should reach for a custom binder only when the built-in behavior is insufficient, such as: - Custom delimiters: Converting a comma-separated string like 1,2,3 into a List<int> without a complex parsing step in the controller. - Non-standard date formats: Parsing dates that do not match ISO 8601 or the current culture. - Encrypted or encoded values: Decrypting a token from the request before it reaches the action logic. - Legacy input shapes: Mapping old API key names or formats to new model properties during a migration.

Registration Options

There are two ways to wire up a custom binder. The first is the [ModelBinder] attribute applied directly to an action parameter or model property, which is explicit and easy to trace. The second is implementing IModelBinderProvider and registering it in dependency injection, which applies the binder globally based on type. The provider approach keeps controllers clean but requires care to avoid matching unintended types; the provider’s GetBinder method is consulted for each parameter, so it should return null quickly for non-matching types. In classic ASP.NET MVC 5, you registered binders in ModelBinders.Binders during application start instead of using DI providers.

Best Practices and Pitfalls

• Keep binders focused: A binder should only translate data, not perform business logic or database lookups.

• Validate input: Binders populate ModelState; always check ModelState.IsValid in the controller before using the model.

• Avoid over-posting: Bind to specific view models or DTOs rather than entity classes to prevent users from setting fields they should not access.

• Performance: Providers run for every parameter; ensure GetBinder returns null quickly for non-matching types to avoid slowing down the request pipeline.

• Error clarity: Add descriptive model errors so the default validation summary displays useful messages to the client.

Unified Controller Hierarchy

In ASP.NET Core, the separation between MVC and Web API is logical rather than architectural. Both controller types derive from ControllerBase, which provides HTTP-specific features like Ok(), NotFound(), and HttpContext access. - Web API controllers: Inherit directly from ControllerBase. They are lightweight and do not carry dependencies related to view rendering. - MVC controllers: Inherit from Controller, which extends ControllerBase to add view support, ViewBag, ViewData, and TempData.

The [ApiController] Attribute

Web API controllers are typically decorated with [ApiController]. This attribute opts the controller into several API-centric behaviours: - Automatic 400 responses: If model validation fails, the framework automatically returns HTTP 400 without requiring a manual ModelState.IsValid check. - Binding source inference: Complex types are bound from the request body by default, while simple types are bound from the route or query string. - Problem details: Model validation failures return standardized RFC 7807 problem detail responses automatically; unhandled exceptions require separate exception handler middleware. - Attribute routing requirement: Routes must be defined with attributes like [Route]; convention-based routing is not supported.

Response Formats and Return Types

The primary functional difference is what gets sent back to the client. - Web API: Returns data objects or ActionResult<T>. Content negotiation serializes the response, with JSON as the default using System.Text.Json. - MVC: Returns IActionResult implementations like ViewResult that render Razor views into HTML.

How Classic MVC 5 Differs

In classic ASP.NET MVC 5 on .NET Framework 4.8, Web API and MVC were physically separate: System.Web.Mvc.Controller lived in one assembly, while System.Web.Http.ApiController lived in another with a different pipeline and configuration. ASP.NET Core unified these into a single framework.

Best Practices

• Use DTOs: Return data transfer objects or view models instead of database entities to prevent over-posting and control serialization.

• Secure endpoints: Enforce HTTPS and apply [Authorize] attributes to protect API resources.

• Choose the right base: Use ControllerBase for APIs to avoid loading view-related dependencies unnecessarily.

• Version your API: Include versioning in routes or headers to maintain compatibility as the API evolves.

Application Lifecycle Events

The file defines a class that inherits from System.Web.HttpApplication, exposing events raised by the ASP.NET runtime. The most important events are Application_Start (runs once when the application domain starts), Application_End (runs on shutdown), Session_Start (fires when a new session begins), Session_End (fires when a session times out or is abandoned, but only in InProc session mode), and Application_Error (fires when an unhandled exception escapes the request pipeline). These hooks let developers run framework-wide logic without touching individual controllers or actions.

Startup Configuration Sequence

In MVC 5, Application_Start is the single entry point for framework initialization. It normally delegates to static registration methods in separate configuration classes. The conventional order is: 1. AreaRegistration.RegisterAllAreas() – registers areas and their routes. 2. FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters) – registers global filters such as HandleErrorAttribute. 3. RouteConfig.RegisterRoutes(RouteTable.Routes) – builds the route table used for controller and action selection. 4. BundleConfig.RegisterBundles(BundleTable.Bundles) – registers CSS/JavaScript bundles.

This order matters because routes must be registered before the first request arrives, and bundles need the BundleTable to be ready.

Global Error Handling

When an exception is not caught by an MVC exception filter, the runtime raises Application_Error. Inside the handler you can retrieve the exception with Server.GetLastError(), log it, and optionally redirect to an error page. A common pitfall is forgetting to call Context.ClearError(), which can cause the error to propagate to the default error page. Still, Application_Error is a last-resort safety net; per-controller or per-action exception filters give finer-grained control and are the preferred place for MVC-specific error handling.

Comparison with ASP.NET Core

ASP.NET Core does not use Global.asax. The table below summarizes the differences:

Best Practices and Common Pitfalls

• Keep Logic Minimal: Avoid heavy business logic or long-running tasks in Application_Start; they delay the first request and can cause timeouts.

• Static State Risks: Do not store mutable request data in static fields inside Global.asax; static state is shared across all requests and can cause race conditions.

• Prefer Exception Filters: Use HandleErrorAttribute or custom IExceptionFilter implementations for MVC errors rather than catching everything in Application_Error.

• Session Events Are Limited: Session_End only works with InProc session state; do not rely on it for critical cleanup in StateServer or SQLServer modes.

• Deployment: The .asax file and its code-behind must both be deployed; a missing code-behind class prevents the application from starting.

Response and Output Caching

Response caching stores the full HTTP response generated by an action so subsequent requests can be served without re-executing the pipeline. You enable it with builder.Services.AddResponseCaching() and app.UseResponseCaching(), then annotate actions with [ResponseCache] to set duration, location and varying parameters. In .NET 8 the newer output caching middleware (AddOutputCache() / UseOutputCache() with the [OutputCache] attribute) is the recommended way to cache full responses; response caching is still supported but is the older API. In classic MVC 5 on .NET Framework 4.8 the equivalent is the [OutputCache] attribute, which does not exist in ASP.NET Core.

In-Memory and Distributed Caching

For storing application data rather than full responses, inject IMemoryCache through dependency injection. Items live in the memory of a single server instance, which suits single-server deployments. For web farms or cloud hosting, use IDistributedCache backed by Redis via the Microsoft.Extensions.Caching.StackExchangeRedis package and its AddStackExchangeRedisCache() extension, so every node shares one cache store.

View (Fragment) Caching

The Cache Tag Helper caches a fragment of a view for a specified time. It is useful for expensive partial views, such as navigation menus or dashboard widgets, without caching the entire page response.

Code Example

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();
builder.Services.AddResponseCaching();
builder.Services.AddMemoryCache();

var app = builder.Build();

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseResponseCaching();   // before UseAuthorization, after UseRouting
app.UseAuthorization();

app.MapDefaultControllerRoute();
app.Run();

// Controllers/ProductsController.cs
public class ProductsController : Controller
{
    private readonly IMemoryCache _cache;
    private readonly AppDbContext _dbContext;

    public ProductsController(IMemoryCache cache, AppDbContext dbContext)
    {
        _cache = cache;
        _dbContext = dbContext;
    }

    [ResponseCache(Duration = 60, Location = ResponseCacheLocation.Any, VaryByParam = "id")]
    public IActionResult Details(int id)
    {
        // Cache-aside: read from the cache first, load and store on miss
        if (!_cache.TryGetValue(id, out Product? product))
        {
            product = _dbContext.Products.Find(id);
            _cache.Set(id, product, TimeSpan.FromMinutes(5));
        }

        return View(product);
    }
}

<!-- Views/Shared/_Dashboard.cshtml -->
<cache expires-after="00:05:00" vary-by="UserId">
    <partial name="_UserDashboard" />
</cache>

Best Practices and Pitfalls

• Vary by parameters: Always set VaryByParam, VaryByHeader or vary-by when responses differ by input; otherwise a user may see another user’s cached data.

• Avoid caching authenticated content: Do not use Location = ResponseCacheLocation.Any for pages containing personal or sensitive information.

• Never cache antiforgery tokens: Forms rendered by the form tag helper contain a per-request token; if the fragment is cached, the token is replayed and validation fails. Exclude the form from the cached fragment or vary the cache by user.

• Prevent over-posting: Never bind entity classes directly from user input; use view models (or [Bind]) to control which properties are accepted.

• Expiration strategy: Use absolute expiration for stable data and sliding expiration for frequently accessed items, so the cache cannot fill with stale entries.

• Do not cache tracked entities: Entities loaded by EF Core are tracked by the context; project to a DTO or use AsNoTracking() before caching to avoid stale or shared tracked instances.

What Bundling Does

Bundling merges several related files into a single file that the browser downloads in one request. - Fewer round trips: a page referencing ten separate CSS files triggers ten HTTP requests; a bundle reduces this to one (or a few). - Better connection usage: browsers limit concurrent connections per host (typically six in modern browsers), so fewer files means less queuing. - Logical grouping: you can bundle vendor libraries separately from application code so cache hits are more effective.

What Minification Does

Minification rewrites a file to be as small as possible without changing its behaviour. - Whitespace and comments removed: these are useful for developers but useless to the browser. - Shorter local names: JavaScript minifiers rename local variables to short identifiers like a and b. - Optional optimisations: some tools remove dead code, inline small constants or shorten literal values.

How They Improve Performance

• Lower latency: each HTTP request carries header overhead and round-trip latency; fewer requests mean the page renders sooner, especially on high-latency mobile networks.

• Smaller downloads: minified files are often 30-60% smaller, which matters for users on slow or metered connections.

• Better caching: bundling vendor libraries into a versioned file lets browsers cache them across pages and even across site updates when the bundle name changes.

• Note that bundling and minification work alongside, not instead of, HTTP compression (gzip or Brotli), which the server applies after minification for further savings.

ASP.NET Core vs Classic MVC 5

Classic ASP.NET MVC 5 on .NET Framework 4.8 includes built-in bundling and minification through the System.Web.Optimization namespace, configured in BundleConfig.RegisterBundles and rendered in views with Styles.Render and Scripts.Render. ASP.NET Core MVC on .NET 8 does not include a built-in bundling and minification framework; the mainstream approach is to run bundling and minification at build time with tooling such as webpack, Vite, esbuild, the BundlerMinifier Visual Studio extension or the BuildBundlerMinifier NuGet package, then serve the produced files from wwwroot as static assets. The request flow is otherwise the same: routing selects the controller and action, the view is rendered, and static files are served directly by the static-file middleware.

Best Practices and Common Pitfalls

• Bundle per page or per group: avoid one giant bundle for the whole site; unused JavaScript still downloads and parses on every page.

• Never serve unminified files in production: publish and serve only the minified output, and keep the original source files out of the published site.

• Use versioned bundle names or a cache-busting token: when a bundle changes, its URL should change (for example with asp-append-version in ASP.NET Core) so browsers fetch the new copy instead of using a stale cache.

• Debugging: keep source maps enabled during development and disable them in production to avoid leaking source code.

• Don’t double-compress: minification and gzip/Brotli are complementary; ensure your server has response compression enabled in addition to minifying.

How WebSockets Work in ASP.NET Core MVC

Unlike normal HTTP requests, a WebSocket connection starts as an HTTP request that the client upgrades. In ASP.NET Core MVC you do not handle this in a controller action; you handle it in middleware that runs early in the request pipeline. The framework exposes the request through HttpRequest.WebSockets, where IsWebSocketRequest tells you whether the client asked to upgrade, and AcceptWebSocketAsync() completes the handshake and returns a WebSocket object you can read from and write to.

The System.Net.WebSockets types and the UseWebSockets() middleware are part of the ASP.NET Core / .NET 8 shared framework, so no extra NuGet package is required.

Middleware Setup and Request Flow

The WebSocket middleware should be registered early in the request pipeline, before any middleware or endpoint that might terminate the request. It can be placed before or after UseRouting(); what matters is that your WebSocket branch sees the upgrade request before the default controller routes consume or reject the path. A common pattern is to branch the pipeline with app.Map("/ws", ...) for a dedicated path.

Managing Multiple Connections

A single WebSocket handler only sees one connection. To broadcast to all clients (for example, live notifications), store each accepted socket in a thread-safe collection such as ConcurrentDictionary<string, WebSocket> and remove it when the close handshake completes. Wrap send operations in a try/catch around each socket, because writing to a broken connection throws, and always call CloseAsync() with WebSocketCloseStatus.NormalClosure when the receive loop ends.

Security Considerations

• Use wss:// in production: WebSocket connections should run over TLS on Linux and Windows alike; browsers increasingly restrict mixed secure/insecure content.

• Validate the Origin header: check context.Request.Headers["Origin"] against an allowlist to prevent cross-site WebSocket hijacking, since cookies are sent with the upgrade request.

• Authenticate before accepting: run your auth check before AcceptWebSocketAsync(), because after the upgrade the normal HTTP auth filters no longer apply.

• Validate and encode messages: treat incoming frames as untrusted input; encode anything you reflect back into HTML views.

SignalR as the Recommended Alternative

For most real-time MVC features such as chat, live dashboards, or notifications, ASP.NET Core SignalR is the officially recommended higher-level library. It automatically chooses WebSockets when available and falls back to other transports, and it adds connection management, groups, hubs, and automatic reconnection. Use raw WebSockets only when you need a custom binary protocol or minimal overhead.

Code Example

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
builder.Services.AddAuthorization();

var app = builder.Build();

app.UseRouting();
app.UseWebSockets(); // Early in the pipeline, before endpoints
app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Map("/ws", app =>
{
    app.Run(async context =>
    {
        if (!context.WebSockets.IsWebSocketRequest)
        {
            context.Response.StatusCode = 400;
            return;
        }

        using var webSocket = await context.WebSockets.AcceptWebSocketAsync();
        await EchoWebSocketAsync(webSocket);
    });
});

app.Run();

static async Task EchoWebSocketAsync(WebSocket webSocket)
{
    var buffer = new byte[1024 * 4];

    var receiveResult = await webSocket.ReceiveAsync(
        new ArraySegment<byte>(buffer), CancellationToken.None);

    while (!receiveResult.CloseStatus.HasValue)
    {
        await webSocket.SendAsync(
            new ArraySegment<byte>(buffer, 0, receiveResult.Count),
            receiveResult.MessageType,
            receiveResult.EndOfMessage,
            CancellationToken.None);

        receiveResult = await webSocket.ReceiveAsync(
            new ArraySegment<byte>(buffer), CancellationToken.None);
    }

    await webSocket.CloseAsync(
        receiveResult.CloseStatus.Value,
        receiveResult.CloseStatusDescription,
        CancellationToken.None);
}

// wwwroot/js/chat.js
// Use wss:// (TLS) in production; ws:// is fine for local development
const socket = new WebSocket("ws://localhost:5001/ws");

socket.onopen = () => socket.send("Hello server");
socket.onmessage = (event) => console.log("Received:", event.data);
socket.onclose = () => console.log("Connection closed");
socket.onerror = (err) => console.error("WebSocket error", err);

Common Pitfalls

• Wrong middleware order: registering the /ws branch or UseWebSockets() after MapControllers()/MapControllerRoute() means another endpoint may handle or reject the upgrade before your handler sees it.

• Not disposing sockets: wrap accepted sockets in using so the underlying stream closes.

• Ignoring EndOfMessage: a single logical message can arrive in multiple frames; accumulate until EndOfMessage is true for variable-length protocols.

• Assuming controllers can accept WebSockets: controller actions run after routing and are not designed for the upgrade handshake.

• Classic ASP.NET MVC 5 differs: on .NET Framework 4.8 there is no UseWebSockets middleware pipeline; you accept WebSockets inside an async HTTP handler (HttpTaskAsyncHandler) via HttpContext.AcceptWebSocketRequest, or you use SignalR, which also supports MVC 5.

Core Architecture

SignalR abstracts the underlying transport mechanism, automatically selecting WebSockets, Server-Sent Events, or Long Polling based on client capability. The central component is the Hub, a server-side class that clients connect to. Hubs define methods callable by clients and can invoke client-side methods directly. Connections are managed by the SignalR middleware, which handles connection lifecycle events such as connecting, reconnecting, and disconnecting. This differs from classic ASP.NET MVC 5, which used the Microsoft.AspNet.SignalR package with OWIN Startup configuration, now deprecated.

Server-Side Implementation

To use SignalR in an ASP.NET Core 8 project, you define a Hub class inheriting from Hub and register the service in Program.cs. The hub endpoint should be mapped before the controller endpoints so the hub route takes precedence during endpoint matching. You can invoke clients using Clients.All, Clients.Group, or Clients.Caller. Authentication is typically handled via standard ASP.NET Core Identity or JWT tokens passed during the connection handshake. Authorization is enforced before hub methods execute, ensuring only permitted users can invoke specific actions.

Client-Side Integration

Clients connect using the SignalR JavaScript client or native SDKs for mobile platforms. The client establishes a connection to the hub endpoint and registers handlers for server-invoked methods. Once connected, the client can call hub methods asynchronously. Reconnection is not automatic by default: the JavaScript client must be configured with withAutomaticReconnect() (or a custom retry policy) to recover from dropped connections, which is important for resilience in unstable network conditions. Developers should handle connection states explicitly to update the UI when the status changes from connecting to connected.

Security and Scaling

Because SignalR maintains persistent connections, securing them is critical. You should authorize hubs using the [Authorize] attribute just like MVC controllers. To scale beyond a single server, you must use a backplane such as Azure SignalR Service or Redis to broadcast messages across multiple instances. Without a backplane, messages sent from one server instance will not reach clients connected to another instance. Additionally, validate all incoming message payloads to prevent injection attacks, similar to model validation in MVC controllers.

Code Example

// ChatHub.cs
using Microsoft.AspNetCore.SignalR;

public class ChatHub : Hub
{
    public async Task SendMessage(string user, string message)
    {
        await Clients.All.SendAsync("ReceiveMessage", user, message);
    }
}

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddSignalR();
var app = builder.Build();
app.MapHub<ChatHub>("/chatHub");   // register hub endpoints before controllers
app.MapControllers();
app.Run();

Best Practices

• Use DTOs: Avoid sending entity classes directly over the wire; serialize only necessary data to reduce payload size.

• Connection Limits: Monitor connection counts per server to prevent resource exhaustion and denial of service.

• Error Handling: Override OnDisconnectedAsync to clean up resources and log unexpected disconnects for debugging.

• Avoid Blocking: Never block async hub methods with .Result or .Wait() to prevent thread pool starvation.

• CSRF Protection: SignalR does not add antiforgery protection by itself, so keep state-changing hub methods behind authentication and authorization and validate payloads explicitly.

What is OWIN

OWIN specifies a single delegate signature that represents the HTTP request pipeline: Func<IDictionary<string, object>, Task>. This delegate, often referred to as the “appFunc,” receives an environment dictionary containing request data and returns a task representing the response generation. The primary goal is to allow developers to write web applications independent of the underlying web server, such as IIS or a self-hosted HTTP listener. Microsoft’s implementation of OWIN is known as the Katana project.

Relationship with ASP.NET MVC 5

In ASP.NET MVC 5, OWIN is not the MVC framework itself but a hosting abstraction layer that sits between IIS and the MVC pipeline. It is commonly utilized for authentication middleware, such as ASP.NET Identity, OAuth, or external login providers like Google and Facebook. Developers configure OWIN components in a Startup class, typically within a Configuration method that accepts an IAppBuilder instance from the Microsoft.Owin package. A typical configuration calls app.UseCookieAuthentication(...) with CookieAuthenticationOptions to set the application cookie and login path, which keeps authentication logic modular and independent of the Global.asax lifecycle.

ASP.NET Core Equivalent

ASP.NET Core does not implement OWIN; instead, it uses a built-in request delegate pipeline based on HttpContext and RequestDelegate. Middleware components are added using extension methods like app.UseAuthentication() or app.UseRouting() within the Program.cs file, with services registered through builder.Services.AddAuthentication() and similar calls. While the conceptual goal of decoupling server and application remains, the API surface is entirely different and optimized for performance and cross-platform hosting. If migrating from MVC 5, OWIN middleware must be rewritten as ASP.NET Core middleware.

Key Benefits and Use Cases

• Server Independence: Applications can run on IIS, IIS Express, or self-hosted in a console application without code changes on .NET Framework.

• Modular Middleware: Authentication and authorization logic can be composed as separate middleware components rather than hardcoded HTTP modules.

• Simplified Testing: Decoupling from IIS allows easier unit and integration testing of the HTTP pipeline.

• External Authentication: OWIN simplified the integration of OAuth 2.0 flows for social logins in MVC 5 applications.

OWIN (MVC 5) versus ASP.NET Core Middleware

Common Pitfalls

• Mixing Frameworks: Do not attempt to use OWIN packages (e.g., Microsoft.Owin) in an ASP.NET Core project; they are incompatible and will cause runtime errors.

• Startup Class Location: In MVC 5, the OWIN Startup class must be discovered via convention or the OwinStartup attribute; placing it in the wrong namespace or omitting the attribute can prevent initialization.

• Ordering Matters: In both OWIN and ASP.NET Core middleware, the order of registration determines execution order. Authentication must precede authorization logic in both pipelines.

Authentication, Authorization, and HTTPS

• Use ASP.NET Core Identity for user management; it handles PBKDF2 password hashing, account lockout, and two-factor authentication.

• Protect controllers or actions with [Authorize]; use roles or policies for fine-grained access control, and [AllowAnonymous] only on login and public pages.

• Enforce encrypted transport with UseHttpsRedirection() and HSTS in production. Classic MVC 5 on .NET Framework relies on IIS bindings and the [RequireHttps] attribute instead.

Input Validation and Over-Posting

• Validate with data annotations ([Required], [StringLength], [EmailAddress]) and always check ModelState.IsValid in POST actions before using the model.

• Bind to view models, never entity classes, to prevent over-posting where a user supplies fields you did not intend to expose, such as roles or prices.

• With [ApiController] an invalid model returns 400 automatically; plain MVC controllers require the manual check.

CSRF and XSS Protection

• The form tag helper (<form asp-action="...">) injects the antiforgery token automatically; validate it with [ValidateAntiForgeryToken] on POST actions or enable AutoValidateAntiforgeryToken globally.

• Razor encodes output by default, which blocks reflected cross-site scripting; use @Html.Raw() only on trusted, sanitized content.

• Add a Content Security Policy header via middleware to restrict where scripts may load from.

SQL Injection and Secrets

• Use parameterized queries with EF Core LINQ or Dapper; never concatenate user input into SQL strings.

• Store connection strings and keys in user secrets (development) or environment variables / Azure Key Vault (production), never in code or committed configuration files.

Code Example

[Authorize]
public async Task<IActionResult> UpdateProfile(ProfileViewModel model)
{
    if (!ModelState.IsValid) return View(model);
    var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    await _repo.UpdateEmailAsync(userId, model.Email);
    return RedirectToAction("Index");
}

// Repository with a parameterized query - no string concatenation
public async Task UpdateEmailAsync(string userId, string email)
{
    const string sql = "UPDATE Users SET Email = @Email WHERE Id = @Id";
    using var connection = new SqlConnection(_connectionString);
    await connection.ExecuteAsync(sql, new { Id = userId, Email = email });
}

<form asp-controller="Account" asp-action="UpdateProfile" method="post">
    <input asp-for="Email" />
    <span asp-validation-for="Email"></span>
    <button type="submit">Save</button>
</form>

Common Pitfalls

• Skipping ModelState.IsValid lets invalid or malicious data reach your database.

• Binding entity classes directly enables over-posting attacks on sensitive fields.

• Disabling Razor encoding or returning user input as JSON without encoding reintroduces XSS.

• Committing appsettings.json with connection strings leaks secrets; use user secrets or environment variables instead.

Layout Fundamentals

A layout is a Razor file conventionally named _Layout.cshtml and stored in the Views/Shared directory. It contains the standard HTML skeleton, including <html>, <head>, and <body> elements, alongside shared CSS and JavaScript references. In ASP.NET Core, these resource links typically utilize Tag Helpers (e.g., <link href="~/css/site.css" rel="stylesheet" />), which resolve ~/ paths to the web root; adding asp-append-version="true" makes the Tag Helper append a cache-busting hash to the URL.

Assigning Layouts to Views

The default layout for a project is usually specified in _ViewStart.cshtml located in the Views folder, which executes before any view in that directory tree. This file sets the Layout property, such as @{ Layout = "_Layout"; }, applying the template globally. Individual views can override this setting by declaring their own Layout property at the top of the file, or disable it entirely by setting Layout = null for pages requiring full control over output.

Content Placeholders and Sections

Within the layout, @RenderBody() marks the location where the primary content of the view is injected. For conditional or optional content blocks, such as page-specific scripts, @await RenderSectionAsync("Scripts", required: false) defines a named section. The view populates these areas using @section Scripts { ... }. If a section is marked as required but omitted by the view, the runtime throws an InvalidOperationException, ensuring critical dependencies are not missed.

Code Example

The following snippets demonstrate a basic layout configuration and a view implementing it.

<!-- Views/Shared/_Layout.cshtml -->
<!DOCTYPE html>
<html>
<head>
    <title>My Application</title>
    <link href="~/css/site.css" rel="stylesheet" asp-append-version="true" />
</head>
<body>
    <nav>...</nav>
    <main>
        @RenderBody()
    </main>
    @await RenderSectionAsync("Scripts", required: false)
</body>
</html>

<!-- Views/Home/Index.cshtml -->
@{
    Layout = "_Layout";
}

@section Scripts {
    <script src="~/js/index.js" asp-append-version="true"></script>
}

<h1>Home Page</h1>

Best Practices and Pitfalls

• Avoid ViewBag in Layouts: Passing data via ViewBag reduces compile-time safety; prefer strongly-typed view models or ViewData keys defined as constants.

• Async Rendering: Always use RenderSectionAsync in ASP.NET Core to support asynchronous view components, unlike MVC 5 which uses synchronous RenderSection.

• Section Safety: Mark sections as required: false unless every view must provide that content, preventing runtime exceptions during development.

• Performance: Keep logic inside _Layout.cshtml minimal because it executes for every request rendering a view, potentially impacting response latency.

Purpose and Mechanism

These templates act as specialized partial views invoked automatically by HTML helpers based on model metadata. When a view calls Html.DisplayFor or Html.EditorFor, the engine searches for a template matching the property’s data type or explicit template name. This abstraction separates data presentation logic from the main view structure, promoting consistency and reducing duplication across the application. They operate after model binding and validation, during the final view rendering step.

Folder Structure and Naming

Templates must reside in specific folders to be discovered by the view engine during view resolution. - DisplayTemplates: Located at Views/Shared/DisplayTemplates or Views/{Controller}/DisplayTemplates. Used for read-only rendering. - EditorTemplates: Located at Views/Shared/EditorTemplates or Views/{Controller}/EditorTemplates. Used for input fields. - Naming Convention: The file name should match the data type (e.g., DateTime.cshtml) or the class name. You can also specify a template name explicitly in the helper method.

Display vs Editor Templates

• Display Templates: Render data for viewing. They typically output plain text or formatted HTML without input elements. Use Html.DisplayFor(model => model.CreatedDate).

• Editor Templates: Render data for editing. They generate input elements suitable for model binding. Use Html.EditorFor(model => model.CreatedDate). Both respect data annotations like [DataType] or [UIHint] to select the appropriate template automatically.

ASP.NET Core vs Classic MVC 5

In ASP.NET Core MVC, Tag Helpers are the preferred method for generating form inputs, while templates remain available for complex types. In classic ASP.NET MVC 5, Editor Templates were the primary mechanism for form generation since Tag Helpers did not exist, making them more central to the framework’s standard usage.

Code Example

Below is a custom DateTime display template and its usage in a view.

Views/Shared/DisplayTemplates/DateTime.cshtml:

@model DateTime?
@if (Model.HasValue)
{
    <span class="date">@Model.Value.ToString("d")</span>
}

Views/Home/Index.cshtml:

@model MyViewModel
@Html.DisplayFor(m => m.CreatedDate)

If CreatedDate is a DateTime, the engine automatically selects the DateTime.cshtml template located in the shared folder.

Best Practices and Pitfalls

• Use View Models: Ensure templates bind to view models rather than entity classes to prevent over-posting and exposure of sensitive fields.

• Avoid Overuse: Prefer Tag Helpers for standard inputs to keep views readable and maintainable in modern Core MVC development.

• Metadata Attributes: Use [UIHint("TemplateName")] on model properties to explicitly guide the engine to a specific template when naming conventions are insufficient.

• Null Handling: Always handle null values in templates, especially for nullable value types, to avoid runtime exceptions during rendering.

• CSRF Protection: Remember that Editor Templates generating forms must still include antiforgery tokens, typically handled by the parent view or Tag Helpers.

How It Works

When a view renders an input field using Tag Helpers such as asp-for, validation attributes on the model cause the rendered HTML to carry HTML5 data-val-* attributes describing the rules. When the page loads in the browser, the jquery-validation-unobtrusive library parses those attributes and configures the jquery-validation engine with the corresponding rules. Validation then runs in the browser as the user types or leaves a field, and a failing field blocks form submission, reducing unnecessary server round-trips. The server still performs model binding and model validation before the action executes, so client-side validation is a usability layer, not a security control.

Required Dependencies

The following client libraries are required and are included in the default project template through LibMan under wwwroot/lib: - jquery: core library for DOM manipulation and event handling. - jquery-validation: the underlying validation engine. - jquery-validation-unobtrusive: the bridge that reads ASP.NET Core’s data-val-* metadata and applies it to the engine.

Scripts must be loaded in this specific order: jQuery, then jquery.validate.min.js, then jquery.validate.unobtrusive.min.js. Loading them out of order causes runtime errors and disables validation. No NuGet package or startup code is needed to turn the feature on; ASP.NET Core MVC emits the unobtrusive metadata by default.

Code Example

The model defines rules with data annotations, the controller verifies state, and the view renders inputs with Tag Helpers and references the scripts.

public class RegisterViewModel
{
    [Required(ErrorMessage = "Email is required")]
    [EmailAddress]
    public string Email { get; set; }

    [Required]
    [StringLength(100, MinimumLength = 6)]
    public string Password { get; set; }
}

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Register(RegisterViewModel model)
{
    if (!ModelState.IsValid)
    {
        return View(model);
    }
    // Process valid data securely
    return RedirectToAction("Success");
}

@model RegisterViewModel

<form asp-action="Register" method="post">
    <div>
        <label asp-for="Email"></label>
        <input asp-for="Email" />
        <span asp-validation-for="Email" class="text-danger"></span>
    </div>
    <div>
        <label asp-for="Password"></label>
        <input asp-for="Password" />
        <span asp-validation-for="Password" class="text-danger"></span>
    </div>
    <button type="submit">Register</button>
</form>

<script src="~/lib/jquery/dist/jquery.min.js"></script>
<script src="~/lib/jquery-validation/dist/jquery.validate.min.js"></script>
<script src="~/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js"></script>

Best Practices and Pitfalls

• Server-Side Authority: client-side validation can be bypassed by any client; always check ModelState.IsValid in the controller action before saving data.

• CSRF Protection: the form Tag Helper emits the antiforgery token automatically, and the action must be decorated with [ValidateAntiForgeryToken] (or use AutoValidateAntiforgeryToken) to verify it.

• Over-Posting Prevention: bind to view models rather than entity classes so user input cannot set properties you did not expose.

• Classic MVC Difference: in ASP.NET MVC 5 on .NET Framework 4.8 the same jQuery libraries are used, but they are registered in BundleConfig.cs and client validation is enabled through Html.EnableUnobtrusiveValidation() / Html.EnableClientValidation() or the matching web.config settings, whereas ASP.NET Core needs no opt-in.

• Custom Logic: for rules that data annotations cannot express, implement IValidatableObject for cross-property server-side checks, write a custom validation attribute, or use [Remote] to call an action from the browser for richer client-side validation.

Including Libraries and Files

Static JavaScript files belong in the wwwroot/js folder and are referenced from the view or, more commonly, from the shared _Layout.cshtml so they load across multiple pages. jQuery is no longer included in the default .NET 8 templates, so you add it with LibMan or link to a CDN with a local fallback.

• External files: Preferred for maintainability and browser caching; referenced with <script src="~/js/site.js"></script>.

• CDN links: Useful for common libraries like jQuery, but you should provide a local fallback in case the CDN is unreachable.

• Load order: Place library scripts such as jQuery before your custom scripts that depend on them, typically just before the closing </body> tag.

Passing Server Data to JavaScript

Never concatenate C# values into JavaScript strings manually, because this creates cross-site scripting (XSS) vulnerabilities. ASP.NET Core has no built-in @Json Razor helper, so use System.Text.Json.JsonSerializer.Serialize wrapped in @Html.Raw.

• Strings and objects: Write var data = @Html.Raw(JsonSerializer.Serialize(Model.Value)); after adding @using System.Text.Json to the view or _ViewImports.cshtml; this ensures proper escaping of quotes and special characters.

• Numbers and booleans: Can be assigned directly, such as var count = @Model.Count;, since they cannot carry script payloads.

• Why @Html.Raw: Razor HTML-encodes output by default, which would turn JSON quotes into " and break the script; @Html.Raw writes the serialized JSON unchanged.

Client-Side Validation

ASP.NET Core MVC integrates with jQuery Validation through the jquery.validate.unobtrusive library. When you include this script alongside jQuery, the framework reads the data annotation attributes rendered on your form inputs and enforces them in the browser before submission. This reduces round trips to the server while keeping validation rules consistent with your C# model.

Best Practices and Security

• Avoid inline scripts for logic: Keep behavior in external .js files to simplify debugging and enable content security policies (CSP).

• Prevent XSS: Always serialize with JsonSerializer.Serialize inside @Html.Raw; never write var name = '@Model.Name'; because quotes in the name could break the script or execute malicious code.

• Minification: ASP.NET Core does not include the built-in bundling system from classic MVC 5 (BundleConfig); use build tools like webpack or Gulp, or the Web Essentials extension, for minification.

• Unobtrusive validation: Ensure jquery.validate.unobtrusive is loaded if you rely on data annotations for client-side checks.

• Classic MVC 5 note: In classic ASP.NET MVC 5 on .NET Framework 4.8, scripts live under the Scripts folder and BundleConfig handles bundling; that framework offered the legacy @Json.Encode helper, which has no direct equivalent in ASP.NET Core.

How It Works

The scaffolding engine inspects the model class you select, reads its public properties and any data-annotation attributes, then merges that metadata into a template to emit ready-to-use .cshtml files.

• Model inspection: the generator reflects over the model type to discover properties, types, and attributes such as [Required], [StringLength], [Display], and [DataType].

• Template merging: in classic MVC 5 the templates are T4 (Text Template Transformation Toolkit) files; in ASP.NET Core the tooling uses Razor-based generator templates instead, since T4 is not part of the .NET Core tooling by default.

• Output: one .cshtml view per selected page, with form fields, labels, validation spans, and links already bound to the corresponding controller actions.

What Gets Generated

When you scaffold a controller with views, or scaffold views for an existing controller, the tool typically emits four to five pages:

Each input is rendered with a label, the appropriate editor, and a validation message span, so client- and server-side validation defined by data annotations is wired up automatically. In ASP.NET Core the form tag helper also injects the antiforgery token, so [ValidateAntiForgeryToken] on the POST action validates it.

Tooling in ASP.NET Core vs MVC 5

• ASP.NET Core MVC (.NET 8): use the Visual Studio Add View / Add Controller wizards, or the CLI tool dotnet-aspnet-codegenerator (installed with dotnet tool install -g dotnet-aspnet-codegenerator, backed by the Microsoft.VisualStudio.Web.CodeGeneration.Design package).

• Classic MVC 5 (.NET Framework 4.8): the Add View dialog offers a scaffolding template dropdown (Create, Edit, Details, Delete, List, Empty) powered by T4 templates; there is no cross-platform CLI equivalent.

Advantages and Limitations

• Speed: a complete CRUD UI is produced in seconds, ideal for prototypes and internal admin screens.

• Consistency: generated views follow the same structure and naming conventions across the application.

• Validation included: data-annotation rules are reflected into the rendered markup.

• Generic output: the code is deliberately simple and usually needs customization for real business rules, layout, and styling.

• Over-posting risk: scaffolding binds every property it sees; if you scaffold directly against an entity class, users can post fields you did not intend to be editable.

• Not a substitute for understanding: you still need to know the request flow (routing, model binding, validation, filters) to debug and extend the generated code.

Best Practices

• Scaffold against view models, not entity classes, to prevent over-posting and keep the UI shape decoupled from the database schema.

• Review generated code before committing; remove unused fields, adjust labels, and apply your layout and styling.

• Keep authorization explicit: add [Authorize] to controllers or actions; scaffolding does not secure endpoints for you.

• Treat scaffolding as a starting point, not final production code; the generated views are a baseline to refine.

• In ASP.NET Core, prefer tag helpers in the generated views; the older HTML helpers (Html.BeginForm, etc.) are the legacy style, and child actions (Html.Action) do not exist in ASP.NET Core and are replaced by view components.

Why Use a View Model

• Over-posting defense: the binder only sets properties that exist on the view model, so internal or sensitive fields never reach the entity from user input.

• View-specific shape: a ProductEditViewModel can flatten related aggregates (product plus a list of categories for a select list) without leaking navigation properties to the view.

• Validation and display metadata: [Required], [StringLength], [Display] and [DataType] attributes describe the form, which may differ from the entity’s persistence rules.

• Separation of concerns: the view depends on a presentation contract, not on the database schema, so entity changes don’t automatically break views.

How View Models Work

1. Define a plain class (a POCO or record) in a ViewModels folder or project, with only the properties the view reads or writes, annotated with data annotations.

2. Map on GET: load the domain entity in the controller, copy the needed fields into a new view model (adding any read-only data such as drop-down lists), and pass it to the view.

3. Validate on POST: the action accepts the view model as a parameter; the framework runs the data annotations and populates ModelState. Check ModelState.IsValid before proceeding.

4. Map back and save: load the tracked entity, copy only the allowed fields from the view model onto it, then persist. Never let the binder write directly onto the entity.

5. Render with Tag Helpers: make the view strongly typed with @model and use Tag Helpers (asp-for, asp-action) — the modern style in ASP.NET Core; HTML helpers like Html.TextBoxFor are the older style.

With [ApiController] on a controller, an invalid model short-circuits with a 400 Bad Request automatically; in a classic MVC controller you check ModelState.IsValid yourself.

Code Example

The view model, controller and view together:

public class ProductEditViewModel
{
    public int Id { get; set; }

    [Required, StringLength(100)]
    [Display(Name = "Product name")]
    public string Name { get; set; } = string.Empty;

    [Required, Range(0.01, 10000)]
    [DataType(DataType.Currency)]
    [Display(Name = "Unit price")]
    public decimal Price { get; set; }

    [Required, Display(Name = "Category")]
    public int CategoryId { get; set; }

    // Read-only data for the drop-down; never bound from user input.
    public SelectList Categories { get; set; } = default!;

    [BindNever] // present in the view model but ignored by model binding
    public string? StockKeeper { get; set; }
}

public class ProductsController : Controller
{
    private readonly IProductRepository _repo;
    private readonly AppDbContext _db;

    public ProductsController(IProductRepository repo, AppDbContext db)
    {
        _repo = repo;
        _db = db;
    }

    public async Task<IActionResult> Edit(int id)
    {
        var product = await _repo.GetAsync(id);          // domain entity
        var categories = await _db.Categories.ToListAsync();

        var vm = new ProductEditViewModel
        {
            Id = product.Id,
            Name = product.Name,
            Price = product.Price,
            CategoryId = product.CategoryId,
            Categories = new SelectList(categories, "Id", "Name")
        };

        return View(vm);                                  // pass the view model, not the entity
    }

    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Edit(ProductEditViewModel vm)
    {
        if (!ModelState.IsValid)                          // re-check data annotations
        {
            vm.Categories = new SelectList(await _db.Categories.ToListAsync(), "Id", "Name");
            return View(vm);                              // redisplay with validation messages
        }

        var product = await _repo.GetAsync(vm.Id);        // load the tracked entity
        product.Name = vm.Name;                           // copy only the allowed fields
        product.Price = vm.Price;
        product.CategoryId = vm.CategoryId;

        await _repo.SaveChangesAsync();
        return RedirectToAction(nameof(Index));
    }
}

@model ProductEditViewModel

<form asp-action="Edit" method="post">
    <input type="hidden" asp-for="Id" />

    <div>
        <label asp-for="Name"></label>
        <input asp-for="Name" />
        <span asp-validation-for="Name"></span>
    </div>

    <div>
        <label asp-for="Price"></label>
        <input asp-for="Price" />
        <span asp-validation-for="Price"></span>
    </div>

    <div>
        <label asp-for="CategoryId"></label>
        <select asp-for="CategoryId" asp-items="Model.Categories"></select>
        <span asp-validation-for="CategoryId"></span>
    </div>

    <button type="submit">Save</button>
</form>

The form Tag Helper automatically emits the antiforgery token, which the [ValidateAntiForgeryToken] attribute verifies on POST.

Best Practices and Common Pitfalls

• Never bind an entity class directly from user input; [Bind] on an entity is a weaker fallback when a view model is impractical.

• Keep view models small and view-specific: one per screen or form, not a shared “everything” bag.

• Rebuild read-only data before returning the view on validation failure — the drop-down list won’t survive the POST round trip.

• Map explicitly with hand-written code, or a mapper configured to update existing entities; avoid mapping tools that blindly overwrite every entity property from the view model.

• Don’t put business logic in the view model; it is a presentation contract. Validation attributes are fine, domain rules are not.

• Use [BindNever] for view-model properties that exist only to render data, so a crafted request can’t set them.

How It Works

• URL generation: The helper accepts an action name, controller name, route values and form method, then uses the IUrlHelper (via Url.Action) to produce the action attribute from the endpoint routing configuration. Calling BeginForm() with no arguments posts back to the current controller and action.

• Tag emission: The opening tag is written immediately to the view’s ViewContext.Writer, not returned as a string, which is why you normally wrap it in @using (...) rather than @Html... alone.

• Disposal writes the end tag: The returned MvcForm implements IDisposable; its Dispose method renders </form>, so the using block defines the form’s content scope.

• HTTP method: A FormMethod value (Get or Post) sets the method attribute. FormMethod.Post is required when the action modifies server state.

Common Overloads

• Html.BeginForm() — posts to the current action and controller.

• Html.BeginForm("Action", "Controller") — explicit action and controller, FormMethod.Post by default.

• Html.BeginForm("Action", "Controller", FormMethod.Post) — explicit method.

• Html.BeginForm("Action", "Controller", new { id = item.Id }) — anonymous route values merged into the generated URL.

• Html.BeginForm("Action", "Controller", FormMethod.Post, new { @class = "form" }) — HTML attributes, where @class escapes the C# keyword.

Antiforgery and Security

Unlike the Form Tag Helper (<form asp-action="...">), Html.BeginForm() does not emit an antiforgery token automatically. For any state-changing POST you must either add @Html.AntiForgeryToken() inside the form and decorate the action with [ValidateAntiForgeryToken], or prefer the tag helper, which injects the hidden token by default when the method is post. Never bind entity classes directly from user input — use a dedicated view model (or [Bind]) to prevent over-posting.

Code Example

@model LoginViewModel

@* Older HTML-helper style; the Form Tag Helper is now recommended *@
@using (Html.BeginForm("Login", "Account", FormMethod.Post, new { @class = "login-form" }))
{
    @Html.AntiForgeryToken() @* required here; the tag helper adds it automatically *@

    <div>
        <label asp-for="Email"></label>
        <input asp-for="Email" />
        <span asp-validation-for="Email"></span>
    </div>

    <div>
        <label asp-for="Password"></label>
        <input asp-for="Password" />
        <span asp-validation-for="Password"></span>
    </div>

    <button type="submit">Sign in</button>
}

The modern equivalent, which produces the same markup plus the antiforgery token without a using block, is:

<form asp-controller="Account" asp-action="Login" method="post" class="login-form">
    <!-- inputs and validation spans as above -->
</form>

Best Practices and Pitfalls

• Prefer Tag Helpers: <form asp-action> is the officially recommended, cleaner style in ASP.NET Core; Html.BeginForm() remains supported but is the older approach inherited from classic MVC.

• Always dispose the MvcForm: forgetting the using (or a manual Dispose) leaves an unclosed <form> in the output.

• Use FormMethod.Post for writes: GET forms append values to the query string and must never mutate data.

• Validate input: check ModelState.IsValid in the action (or use [ApiController], which returns a 400 automatically when validation fails), and re-render the form with validation messages when it fails.

• Scope data with view models: bind only the properties the user is allowed to submit.

Request Flow and Validation

Validation occurs during the model binding stage, which happens after routing and controller action selection but before your action logic executes. The binding system maps incoming request values to your action parameters and evaluates any validation attributes attached to those types. Any failures are stored in the ModelState dictionary, which remains available for the life of that request.

Data Annotations

You declare rules using attributes from System.ComponentModel.DataAnnotations applied to your view model properties. Common attributes include: - [Required]: Ensures the field is not null or empty. - [StringLength]: Enforces minimum and maximum character limits. - [EmailAddress] and [Range]: Validate format and numeric boundaries. - [RegularExpression]: Matches input against a specific pattern.

Checking Results in the Controller

For standard MVC controllers deriving from Controller, you manually check ModelState.IsValid. If it is false, redisplay the form with the submitted values and error messages. If you use the [ApiController] attribute, the framework automatically returns a 400 Bad Request response when the model is invalid, so manual checking is unnecessary for APIs.

Code Example

The following snippets show a view model, a controller action, and a view using Tag Helpers.

using System.ComponentModel.DataAnnotations;

public class RegisterViewModel
{
    [Required(ErrorMessage = "Email is required")]
    [EmailAddress]
    [StringLength(100)]
    public string Email { get; set; }

    [Required]
    [StringLength(12, MinimumLength = 8)]
    public string Password { get; set; }
}

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Register(RegisterViewModel model)
{
    // Server-side check is mandatory even with client-side validation
    if (!ModelState.IsValid)
    {
        return View(model);
    }

    // Process valid data securely
    return RedirectToAction("Index");
}

@model RegisterViewModel

<form asp-action="Register" method="post">
    <div>
        <label asp-for="Email"></label>
        <input asp-for="Email" />
        <span asp-validation-for="Email"></span>
    </div>
    <button type="submit">Register</button>
</form>

@section Scripts {
    <partial name="_ValidationScriptsPartial" />
}

Best Practices and Pitfalls

• Use View Models: Never bind database entity classes directly to user input to prevent over-posting attacks; create dedicated input models instead.

• Client-Side Validation: ASP.NET Core scaffolding includes jQuery Unobtrusive Validation, which mirrors server rules in the browser for better UX, but never trust it for security.

• CSRF Protection: Always pair POST actions with [ValidateAntiForgeryToken] and the form Tag Helper, which emits the required antiforgery token.

• Custom Rules: Implement IValidatableObject on the model or create custom ValidationAttribute classes when rules span multiple properties.

• Classic MVC 5: In MVC 5 on .NET Framework 4.8, the attributes and ModelState.IsValid pattern are identical, though HTML helpers like Html.BeginForm are the older style compared to Tag Helpers.

Core Architecture

Entity Framework Core (EF Core) serves as the object-relational mapper (ORM), translating C# classes into database tables and LINQ queries into SQL. Instead of creating database contexts manually, you register them in the dependency injection container with a scoped lifetime. This ensures one context instance per HTTP request, which tracks changes efficiently and prevents concurrency issues within a single operation.

Configuration and Registration

Connection strings reside in appsettings.json and are accessed via the IConfiguration interface during startup. In Program.cs, you call services.AddDbContext<TContext> to bind the context to its options, typically reading the connection string from configuration. For development secrets, use the Secret Manager tool rather than hardcoding credentials. Database schema changes are handled through EF Core Migrations, allowing version-controlled updates via the CLI.

Controller Integration

Controllers receive the DbContext instance through constructor injection. During the request flow, routing selects the controller and action, then model binding and validation occur before your action code executes; you should check ModelState.IsValid before persisting data. Action methods should use asynchronous EF Core methods like ToListAsync() or FirstOrDefaultAsync() to avoid blocking threads. Since the container manages the context lifecycle, you do not need to manually dispose of it; the framework handles disposal at the end of the request scope.

Comparison with Classic MVC 5

In classic ASP.NET MVC 5 on .NET Framework, dependency injection was not built-in by default, so developers often instantiated contexts manually within controllers or used a base controller pattern. This frequently led to context disposal issues or shared contexts across requests, whereas ASP.NET Core enforces scoped lifetimes natively.

Security and Best Practices

EF Core automatically parameterizes queries generated from LINQ, which prevents SQL injection attacks. Never concatenate user input into raw SQL strings unless using explicit parameterization with FromSqlRaw. Keep sensitive connection strings out of source control by using environment variables or Azure Key Vault in production. Additionally, avoid exposing entity classes directly as API models; use view models to prevent over-posting and shield internal database structure. When posting forms, ensure [ValidateAntiForgeryToken] is applied to protect against CSRF attacks.

What is Entity Framework Core

EF Core simplifies data persistence by mapping database tables to C# classes known as entities. The central component is the DbContext, which represents a session with the database and exposes DbSet<T> properties for querying entities. It supports LINQ queries, change tracking and automatic schema migrations created with the .NET CLI or Package Manager Console. Unlike raw ADO.NET, EF Core generates the SQL for you, which reduces boilerplate and, when queries are written through LINQ or parameterized APIs, keeps parameter values out of the SQL string so injection is far less likely.

Integration with ASP.NET Core MVC

In ASP.NET Core, EF Core is registered in the dependency injection (DI) container at startup, typically in Program.cs with AddDbContext<T>. The context is registered with a scoped lifetime, so one instance is created per HTTP request and disposed at the end of it. Controllers and services then receive the context through constructor injection, which keeps controllers thin and testable. In classic MVC 5 on .NET Framework 4.8, the counterpart is Entity Framework 6: there is no built-in DI container, so the DbContext is typically instantiated directly in a controller or wrapped in a hand-written repository, and the developer is responsible for disposing it.

Role in the Request Flow

Data access happens after routing, controller and action selection, model binding and model validation have completed. When the action method runs, it calls the injected DbContext or a service that wraps it, and the pipeline then continues with the action result, filters and view rendering. The typical sequence inside the action is:

1. The controller requests data through a DbSet<T> or a repository method.

2. EF Core translates the LINQ expression into SQL and executes it against the database.

3. The returned rows are materialized into entity instances, with change tracking enabled by default.

4. The controller maps the entities to a view model and passes it to the view.

5. On writes, SaveChanges inspects tracked entities and issues the minimal INSERT, UPDATE and DELETE statements in one transaction.

Database calls should be asynchronous (ToListAsync, SaveChangesAsync) so that request-handling threads are returned to the pool while the database works, which avoids thread pool starvation under load.

Best Practices and Pitfalls

• Async by default: use the async EF Core methods end to end and never block on them with .Result, especially in ASP.NET Core where sync-over-async deadlocks and pool starvation are the usual consequences.

• Never bind entity classes directly from user input: accept a view model (or use [Bind]) so an attacker cannot populate navigation or sensitive properties — the over-posting (mass assignment) vulnerability.

• Keep the context scoped: a DbContext is not thread-safe and should not be cached in a static field or shared across requests; one per request is the intended lifetime.

• Use AsNoTracking() for read-only queries: it skips change tracking and saves the per-entity snapshot cost, which matters for large result sets.

• Store connection strings outside source control: user secrets in development, environment variables or a managed secret store such as Azure Key Vault in production.

• Validate before saving: validate input with data annotations and check ModelState.IsValid (with [ApiController] an invalid model returns 400 automatically) before calling SaveChangesAsync.

• Watch the generated SQL: review it during development to catch lazy-loading-triggered N+1 queries and inefficient translations; eager-load navigation properties explicitly with Include where needed.

How Migrations Work

• Model as source of truth: your entity classes and the DbContext configuration (Fluent API in OnModelCreating, data annotations on entities) describe the desired schema.

• Snapshot: EF Core keeps a model snapshot in the Migrations folder; when you add a migration, it compares the current model to that snapshot and generates only the difference.

• Migration files: each migration has an Up method (apply changes) and a Down method (revert them), plus a designer file and an entry in the snapshot.

• __EFMigrationsHistory: a table in the database recording which migrations have already been applied, so Update-Database or Database.Migrate() skips ones already run.

Creating and Applying Migrations

Install the tool and add the first migration, then update the database:

dotnet tool install --global dotnet-ef          # one-time install of the EF Core CLI tool
dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Design

dotnet ef migrations add InitialCreate          # scaffolds the migration from the DbContext model
dotnet ef database update                        # applies pending migrations to the database

The same operations in Visual Studio’s Package Manager Console: Add-Migration InitialCreate and Update-Database.

Applying Migrations at Startup

For deployments where you cannot run CLI commands, apply pending migrations when the app starts. This should be done after app.Build(), inside a scope, and never in parallel with other startup database access:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

var app = builder.Build();

// Apply pending migrations at startup (suitable for simple deployments)
using (var scope = app.Services.CreateScope())
{
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
    db.Database.Migrate();
}

app.MapControllers();
app.Run();

For production, prefer generating a tested SQL script (dotnet ef migrations script --idempotent -o migrate.sql) and applying it through your deployment pipeline, so the schema change is reviewed and rolled back like any other release artifact.

Seeding and Best Practices

• Seed data: override OnModelCreating and use HasData for reference/lookup data so it is part of the migration; avoid calling SaveChanges for seeding in Program.cs unless the data depends on runtime values.

• Review generated code: always open the migration and check column types, indexes and constraints before applying it — EF Core’s inference is not always what you intend, especially for defaults and precision.

• Never delete applied migrations: if a migration has been pushed to any shared database, revert it with database update <previous> and then migrations remove instead of deleting the file, so the history table stays consistent.

• One migration per meaningful change: batch related changes into a single, descriptively named migration rather than one migration per property.

• Test both directions: apply the migration to a copy of the production database and verify the Down path works before shipping a risky change.

• Keep connection strings out of code: store them in appsettings.json, user secrets, or environment variables, and never commit production credentials.

• Back up before large migrations: wide table alterations or data-moving changes should be tested against a restored production backup first.

How It Works

LINQ queries are built against objects that implement IQueryable<T> — in practice an EF Core DbSet<T>, or an in-memory List<T> wrapped with AsQueryable(). The provider translates the query into SQL when the query is enumerated; until then, execution is deferred. That distinction drives most real-world pitfalls.

• Method (fluent) syntax: db.Products.Where(p => p.Price > 10).OrderBy(p => p.Name) — the dominant style in ASP.NET Core code.

• Query syntax: from p in db.Products where p.Price > 10 orderby p.Name select p — compiles to the same calls; some teams prefer it for complex joins or grouping.

• Deferred execution: nothing hits the database until you enumerate with foreach, ToList(), FirstOrDefault(), Count(), etc.

• Immediate execution: ToList(), ToArray(), ToDictionary(), Count(), Any() run the query right away — important when a query must finish before the DbContext is disposed at the end of the request.

Common Query Patterns

Async Queries

In controllers, prefer the async overloads so thread pool threads are released while the database works: ToListAsync(), FirstOrDefaultAsync(), AnyAsync(), SaveChangesAsync(). This scales noticeably better under load than blocking ToList().

Code Example

public class ShopController : Controller
{
    private readonly ShopContext _db;

    // The DbContext is injected by the ASP.NET Core DI container
    public ShopController(ShopContext db) => _db = db;

    // GET /shop?page=2
    public async Task<IActionResult> Index(int page = 1)
    {
        const int pageSize = 20;

        // Projection to a view model: only needed columns are selected,
        // and users can never bind directly to the Product entity
        var products = await _db.Products
            .Where(p => p.IsActive)                 // server-side filter
            .OrderBy(p => p.Name)                   // required before Skip/Take
            .Skip((page - 1) * pageSize)            // paging
            .Take(pageSize)
            .Select(p => new ProductSummaryVm
            {
                Id = p.Id,
                Name = p.Name,
                Price = p.Price,
                CategoryName = p.Category.Name      // navigation property
            })
            .ToListAsync();                         // executes the query

        return View(products);
    }

    public async Task<IActionResult> Details(int id)
    {
        // Include avoids a second query per product (N+1)
        var product = await _db.Products
            .Include(p => p.Category)
            .Include(p => p.Reviews)
            .FirstOrDefaultAsync(p => p.Id == id);

        return product == null ? NotFound() : View(product);
    }
}

Best Practices and Pitfalls

• Beware untranslatable expressions: when EF Core cannot translate part of a Where or Select to SQL, it throws at runtime rather than silently evaluating client-side (that fallback was removed in EF Core 3.0). Keep non-translatable logic — arbitrary C# methods with no SQL mapping — out of the query, or materialize first and finish in memory.

• Avoid N+1 queries: a loop that touches a navigation property fires one extra query per row — use Include or a single Select projection instead.

• Never bind entity models directly from forms: project to a view model so LINQ queries feed only the data the view needs, which also prevents over-posting.

• Dispose the context per request: the default AddDbContext uses Scoped lifetime, so deferred queries must be enumerated before the action returns.

• Keep queries out of views: do LINQ in the controller or a service; Razor views should only iterate the already-materialized model.

• Use Any rather than Count() > 0 and FirstOrDefault/SingleOrDefault instead of Where(...).FirstOrDefault() when you need a single row.

Core Concept

The pattern mediates between the domain model and the data mapping layer. It provides a centralized location for data access logic, promoting separation of concerns and making the system easier to unit test. Instead of calling DbContext methods directly throughout the application, controllers depend on a repository interface. This logic executes during the controller action phase, occurring after routing, model binding, and validation, but before the action result is generated.

Implementation Steps

To apply this pattern, first define a generic interface specifying methods like GetAll, GetById, Add, and Update. Next, create a concrete class that implements this interface using an injected DbContext. The concrete class translates interface calls into LINQ queries or EF Core tracking operations. Ensure the repository does not leak persistence-specific details like IQueryable unless intentionally designed for flexible querying, as this can weaken the abstraction.

Dependency Injection and Registration

ASP.NET Core relies heavily on built-in dependency injection. Repositories are typically registered with a scoped lifetime in Program.cs, matching the DbContext lifetime. This ensures that a single repository instance and a single DbContext instance are used per HTTP request, preventing concurrency issues and enabling change tracking. In classic MVC 5 on .NET Framework, registration was often handled manually via a composition root or frameworks like Unity in Global.asax, rather than the native container used in Core.

Code Example

// Assume Product and AppDbContext are defined in the domain layer
public interface IProductRepository
{
    Task<Product?> GetByIdAsync(int id);
    Task AddAsync(Product product);
}

public class ProductRepository : IProductRepository
{
    private readonly AppDbContext _context;
    public ProductRepository(AppDbContext context) => _context = context;

    public async Task<Product?> GetByIdAsync(int id)
        => await _context.Products.FindAsync(id);

    public async Task AddAsync(Product product)
    {
        await _context.Products.AddAsync(product);
        await _context.SaveChangesAsync();
    }
}

Registration in Program.cs:

builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

Best Practices and Pitfalls

Avoid creating a repository for every aggregate if EF Core already provides sufficient abstraction; unnecessary layers can add complexity without benefit. Use view models to prevent over-posting when passing data from controllers to views, rather than exposing entities directly. Always validate models using data annotations and check ModelState.IsValid in controllers before passing data to repositories. Remember that DbContext itself implements a unit of work pattern, so combining repositories with explicit unit of work classes may be redundant unless managing multiple contexts.

Core Concept

The pattern maintains a list of objects affected by a business transaction and coordinates the writing out of changes. Instead of saving every modification immediately, the system tracks changes to entities during the request lifecycle. At the end of the operation, it either commits all changes in a single transaction or discards them if an error occurs. This prevents partial updates that could leave the database in an inconsistent state, such as deducting inventory without creating the corresponding order record.

Implementation in ASP.NET Core MVC

In modern ASP.NET Core development, you rarely implement Unit of Work manually. The DbContext class acts as the Unit of Work and DbSet<TEntity> collections act as repositories. It is registered in the dependency injection container with a scoped lifetime using builder.Services.AddDbContext<TContext>() in Program.cs, meaning one instance is created per HTTP request. Controllers receive the context through constructor injection and call SaveChangesAsync at the end of an action to commit all tracked changes in a single transaction. For complex operations involving multiple contexts or external services, explicit transactions are available via _context.Database.BeginTransactionAsync().

Importance and Benefits

• Data Consistency: Ensures related changes (e.g., creating an order and order lines) succeed or fail together.

• Performance: Batches database commands into a single round-trip when SaveChangesAsync is called, rather than executing one query per entity modification.

• Transaction Management: Simplifies handling of transactions without manually managing SqlConnection or TransactionScope in most cases.

• Concurrency Control: Works with optimistic concurrency tokens to detect conflicts during the commit phase.

Difference in Classic ASP.NET MVC 5

In classic ASP.NET MVC 5 on .NET Framework 4.8, developers often created explicit UnitOfWork classes wrapping an ObjectContext or DbContext to manage transactions across multiple repositories manually. While the pattern logic remains the same, ASP.NET Core integrates this directly into the framework’s dependency injection and middleware pipeline, reducing boilerplate code.

Best Practices and Pitfalls

• Scoped Lifetime: Always register DbContext as scoped. A singleton context can cause concurrency issues and memory leaks, while a transient context may not track changes correctly across the request.

• Async Operations: Use SaveChangesAsync instead of SaveChanges to avoid blocking threads in web applications.

• Avoid Long-Lived Units: Do not hold the context open across multiple HTTP requests; it should align with the request lifetime.

• Explicit Transactions: For complex operations involving multiple contexts or external services, use explicit transactions via _context.Database.BeginTransactionAsync().

How It Works

• Implicit transaction: Each SaveChanges()/SaveChangesAsync() opens the connection if necessary, starts a transaction, applies all pending INSERT/UPDATE/DELETE statements, and commits. If any statement fails, the whole transaction rolls back. This covers most controller actions.

• Explicit transaction: await using var tx = await _db.Database.BeginTransactionAsync(); groups multiple SaveChangesAsync() calls into one atomic unit. Call await tx.CommitAsync() at the end; on failure call await tx.RollbackAsync(). The await using also disposes the transaction.

• ADO.NET interop: tx.GetDbTransaction() exposes the underlying DbTransaction. Raw commands executed on the same connection from _db.Database.GetDbConnection() can enlist by assigning command.Transaction.

• Ambient/coordinated transactions: System.Transactions.TransactionScope can coordinate multiple DbContext instances or ADO.NET connections, but opening a second connection usually escalates to a distributed transaction. On SQL Server this requires MSDTC and is Windows-only, so it is not the recommended path for ordinary multi-save work. Use context.Database.UseTransaction(...) when an external transaction is already open.

Implicit vs Explicit Transactions

Code Example

public class OrdersController : Controller
{
    private readonly AppDbContext _db;

    public OrdersController(AppDbContext db) => _db = db;

    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Create(OrderViewModel model)
    {
        if (!ModelState.IsValid)
            return View(model);

        // Explicit transaction: order header and line items must be saved atomically
        await using var tx = await _db.Database.BeginTransactionAsync();
        try
        {
            var order = new Order
            {
                CustomerId = model.CustomerId,
                PlacedAt = DateTime.UtcNow
            };
            _db.Orders.Add(order);
            await _db.SaveChangesAsync();

            foreach (var line in model.Lines)
            {
                _db.OrderItems.Add(new OrderItem
                {
                    OrderId = order.Id,
                    ProductId = line.ProductId,
                    Quantity = line.Quantity
                });
            }
            await _db.SaveChangesAsync();

            await tx.CommitAsync();
            return RedirectToAction(nameof(Index));
        }
        catch
        {
            await tx.RollbackAsync();
            throw;
        }
    }
}

Classic ASP.NET MVC 5 / EF6

• Synchronous API: On .NET Framework 4.8 with EF6, Database.BeginTransaction() is synchronous and returns DbContextTransaction from System.Data.Entity.Infrastructure; there is no BeginTransactionAsync or IDbContextTransaction.

• Coordinating multiple contexts: TransactionScope is the usual way to coordinate multiple DbContext instances in EF6, but it also escalates to MSDTC for distributed transactions.

• Shared guidance: The guidance to commit last, keep transactions short, and avoid binding entities directly still applies.

Best Practices and Common Pitfalls

• Commit last, rollback on exception: forgetting CommitAsync() leaves the transaction rolled back when disposed, which is safe but can hide data-loss bugs; swallowing exceptions without rollback is the real danger.

• Keep transactions short: the scoped DbContext lives for one HTTP request, so a transaction should span one action, not multiple requests. For long-running background workflows, use IDbContextFactory inside a hosted service instead of holding one transaction open across requests.

• Prefer BeginTransactionAsync: it opens the connection asynchronously, so you do not need to call OpenConnectionAsync() first.

• Use savepoints for partial recovery (EF Core 7+): context.Database.CreateSavepoint(name), RollbackToSavepoint(name), and ReleaseSavepoint(name) are synchronous DatabaseFacade methods that let you undo part of a transaction without aborting it.

• Do not mix connections: a transaction belongs to one DbContext/connection; sharing it across contexts requires enlisting via GetDbTransaction().

• Test the failure path: verify that a duplicate-key error after the first SaveChangesAsync() leaves no orphaned order row.

Core Approach

In ASP.NET Core, controllers are plain classes designed for dependency injection. You do not need to start a web server or host the application to test a single action. - Instantiate directly: Create the controller with new, passing mock objects into the constructor. - Mock dependencies: Replace repositories or services with mocks so no real I/O occurs. - Invoke actions: Call the action method like any other method, awaiting it if it is asynchronous. - Assert results: Check the returned IActionResult type and the model passed to the view.

In classic MVC 5 on .NET Framework 4.8, controllers rely more heavily on HttpContext.Current, often requiring you to populate ControllerContext manually before calling actions.

Asserting Action Results

Action methods return IActionResult, so your assertions focus on the concrete result type rather than HTTP details. - ViewResult: Assert the view name and the Model property contains the expected data. - RedirectToActionResult: Verify the target action and controller name for navigation logic. - NotFoundResult or StatusCodeResult: Confirm correct status codes for missing resources. - ModelState: Check controller.ModelState.IsValid if the action validates input before returning.

Use Assert.IsType<T> from xUnit to confirm the result type safely before casting.

Code Example

The following shows a controller depending on a service, and an xUnit test that mocks that service.

// Controller in ASP.NET Core MVC
public class ProductsController : Controller
{
    private readonly IProductService _service;
    public ProductsController(IProductService service) => _service = service;

    public async Task<IActionResult> Details(int id)
    {
        var product = await _service.GetByIdAsync(id);
        if (product == null) return NotFound();
        return View(product);
    }
}

// Unit test using xUnit and Moq
public class ProductsControllerTests
{
    [Fact]
    public async Task Details_ExistingId_ReturnsViewResultWithModel()
    {
        // Arrange: mock the dependency so no database is hit
        var mock = new Mock<IProductService>();
        mock.Setup(s => s.GetByIdAsync(It.IsAny<int>()))
            .ReturnsAsync(new Product { Id = 1, Name = "Tool" });
        var controller = new ProductsController(mock.Object);

        // Act: call the action directly
        var result = await controller.Details(1) as ViewResult;

        // Assert: verify result type and model content
        Assert.NotNull(result);
        Assert.IsType<Product>(result.Model);
    }
}

Best Practices and Pitfalls

• Keep controllers thin: Controllers should coordinate services and return results; put business logic in the service layer so it can be tested separately.

• Do not test the framework: Avoid asserting framework behaviors, such as whether a view file exists or how routing resolves URLs; that belongs in integration tests.

• Avoid HttpContext in actions: If an action reads HttpContext, you must set controller.ControllerContext.HttpContext in the test, which makes tests brittle.

• Use integration tests for pipelines: For full request validation, including filters and middleware, use WebApplicationFactory<T> instead of instantiating the controller.

• Prefer constructor injection: Do not use service location or static globals inside controllers, as they prevent easy mocking during tests.

What Mocking Is and Why It Matters

A unit test should verify one piece of logic, not the whole stack. When an action method reads from a database, calls a payment gateway or logs telemetry, those dependencies bring slowness, configuration, network calls and flakiness into the test. A mock substitutes for them:

Mocking frameworks such as Moq generate these stand-ins dynamically from an interface or from virtual members of a class.

What to Mock in ASP.NET Core MVC

• Application services: anything injected through constructor injection behind an interface — repositories, billing clients, email senders.

• Data access: abstract DbContext behind a repository, or use the EF Core in-memory/SQLite provider instead of mocking DbSet<T> directly.

• Logging: prefer NullLogger<T> or a test logger provider that writes to the test output (e.g. via the Microsoft.Extensions.Logging.XUnit package) over mocking ILogger<T>; asserting on log output couples tests to formatting.

• HTTP calls: use IHttpClientFactory with a HttpMessageHandler mock, or tools like WireMock.Net, rather than mocking HttpClient.

• Identity: mock UserManager<TUser> or RoleManager<TRole>; for User claims, build a ControllerContext with a fake ClaimsPrincipal.

For full request pipeline tests — routing, filters, model binding, antiforgery — use WebApplicationFactory<TEntryPoint> to run the app in-memory with real middleware and only external services replaced.

How It Works

Tests follow the Arrange-Act-Assert shape. In the arrange phase you create a mock, configure its members with Setup, and inject it into the controller. In the act phase you invoke the action. In the assert phase you check the returned IActionResult (view name, model, status code) and optionally Verify that the mock was called as expected. Mocks let you also simulate edge cases that are hard to reproduce with real infrastructure: a repository throwing TimeoutException, an empty result set, or an unauthorized user.

Best Practices and Common Pitfalls

• Mock your own abstractions, not framework types: mock interfaces you own; wrap third-party or static APIs behind an adapter so seams exist.

• Don’t mock what you don’t own in a way that duplicates its behavior: mocking EF Core’s query translation leads to tests that pass but hide real SQL errors; prefer a repository interface or the EF Core test providers.

• Verify behavior, not just state: asserting Times.Once on AddAsync catches wiring bugs that result assertions miss.

• Keep setups minimal: over-specified mocks with It.IsAny everywhere make tests brittle; set up only what the test exercises.

• Prefer constructor injection: it makes dependencies explicit and mockable; avoid HttpContext.Current-style statics (classic MVC 5 on .NET Framework 4.8 relied on these, and they are absent from ASP.NET Core).

• Balance unit and integration tests: mocks are fast but cannot catch routing, filter, model-binding or antiforgery mistakes; cover those with WebApplicationFactory-based integration tests.

Unit Testing Frameworks

For assertions, FluentAssertions provides readable, chainable assertions that make failure messages easier to understand.

Mocking Libraries

• Moq: the dominant mocking framework; creates substitutes for interfaces such as repositories or ILogger<T>.

• NSubstitute and FakeItEasy: simpler-syntax alternatives to Moq.

Mocks isolate the controller from dependencies like databases or external services, so a unit test exercises only the action logic and not the whole pipeline.

Integration Testing

• Microsoft.AspNetCore.Mvc.Testing: ships the WebApplicationFactory<T> base class, which spins up an in-memory test server hosting your real application.

• You can swap services (for example, replace a real DbContext with an in-memory provider or a test container) by overriding ConfigureWebHost.

• Tests send real HTTP requests through HttpClient and assert on status codes, headers and response bodies.

This validates routing, model binding, filters, middleware and the complete pipeline rather than just one controller method.

End-to-End and UI Testing

• Playwright for .NET: modern browser automation; preferred over Selenium for new projects.

• Selenium WebDriver: the established cross-browser option.

These drive a real browser against a test-hosted or deployed site and verify rendered HTML and complete user flows.

Best Practices

• Keep unit tests fast and isolated; never hit a real database or external API inside them.

• Use integration tests for the request pipeline: routing, model validation, filters and authentication middleware.

• Run tests in CI on every pull request with dotnet test.

• Name test projects <AppName>.Tests and keep them in the same solution as the application.

• For classic ASP.NET MVC 5 on .NET Framework 4.8, WebApplicationFactory<T> is not available; unit tests use the same xUnit/NUnit/MSTest and Moq approach, while integration tests typically run against IIS Express with Selenium or a similar browser automation tool.

Logging and Diagnostic Tools

• ILogger interface: built-in abstraction with Console, Debug, and EventSource providers; use AddFilter to enable debug logging for namespaces like Microsoft.AspNetCore.Mvc.

• Serilog: production-grade provider that adds correlation IDs and structured properties; configure via AddSerilog.

• Azure Application Insights: cloud APM that captures requests, dependencies, exceptions, and traces; integrate with AddApplicationInsights.

• Log levels: Trace, Debug, Information, Warning, Error, Critical—set minimum levels per namespace to filter noise.

• Visual Studio Diagnostic Tools: shows CPU, memory, and events during a debugging session; helpful for performance bottlenecks.

Middleware and Request Flow Inspection

• Exception handling middleware: UseDeveloperExceptionPage() in Development shows stack traces and query strings; UseExceptionHandler() in Production redirects to a friendly error page.

• Request flow order: routing → controller and action selection → model binding → model validation → filters → action result → view rendering.

• Filter execution order: authorization, resource, action, exception, result. A silent failure often means an authorization filter blocked the request before the action ran.

• Pipeline tracing: insert temporary logging middleware to see the exact order and timing of each middleware component.

Model Binding and Validation Checks

• ModelState.IsValid: always check in actions to catch data annotation violations; log ModelState.Values to identify which properties failed.

• [ApiController] behavior: invalid models automatically return 400 Bad Request, which can surprise clients expecting a view.

• Over-posting prevention: use view models (or [Bind]) to restrict bound properties; unexpected data changes usually trace back to direct entity binding.

• CSRF errors: [ValidateAntiForgeryToken] checks the token added by the form tag helper; missing or expired tokens appear in the logs as 400 responses.

Debugging Tools Comparison

Best Practices and Common Pitfalls

• Never log sensitive data: passwords, tokens, and PII must be masked or omitted, even in debug logs.

• Correlation IDs: propagate a unique request ID across services to follow a single transaction in distributed systems.

• TempData semantics: ViewData and ViewBag last one request; TempData survives one redirect and clears once read—reading it too early causes missing data.

• Enforce HTTPS during debugging: catches mixed-content, secure-cookie, and redirect-loop issues early.

• Classic MVC 5 contrast: debugging centered on Global.asax, Trace.axd, and HttpContext.Current; ASP.NET Core replaces these with the unified middleware pipeline and dependency injection.

Where the Time Goes

Work through the request pipeline in order, since each stage can be the culprit:

1. Routing and endpoint resolution — usually negligible, but misconfigured middleware ordering can add overhead.

2. Model binding and validation — large payloads or custom binders can be slow.

3. Authorization and other filters — synchronous filters doing I/O block the request.

4. Action execution — the most common offender: database calls, external HTTP calls, serialization.

5. View rendering — complex Razor views, partial views, and missing caching.

6. Response writing — large payloads without compression.

Measurement Tools

Common Bottlenecks

• Blocking async calls: .Result or .Wait() on async methods ties up thread-pool threads and can deadlock; use await end to end.

• N+1 queries: loading a list of entities and then lazy-loading a navigation property per row. Fix with eager loading (Include) or splitting queries.

• Change tracking overhead: read-only queries should use AsNoTracking().

• Missing indexes: a query that scans a large table shows up as repeated long durations in SQL logs.

• No caching: recompute or re-fetch data that changes rarely. Use IMemoryCache for an in-process cache, IDistributedCache (e.g. Redis) across servers, [ResponseCache] for HTTP caching, and in .NET 8 the built-in output caching via AddOutputCache() / [OutputCache].

• Synchronous I/O in hot paths: file or network reads should be async.

• Large responses: enable response compression and paginate API results.

• View rendering: cache expensive view data in IMemoryCache rather than recomputing per request.

Best Practices and Pitfalls

• Set a performance budget (e.g. P95 under 300 ms) and measure against it; averages hide tail latency.

• Profile in an environment close to production — dev machines often have different data volumes and latency.

• Optimize the biggest item first, then re-measure; micro-optimizations rarely matter.

• Check the database before the code — adding one index often beats rewriting C#.

• Don’t cache without invalidation — stale data is a bug, not a feature.

• Avoid premature optimization — clean, async, query-efficient code is usually fast enough.

In classic ASP.NET MVC 5 on .NET Framework 4.8 the approach is the same, but you use tools such as Glimpse (now deprecated; replaced by Application Insights and MiniProfiler), the Visual Studio profiler, and ETW/PerfView instead of the dotnet-* CLI diagnostics.

How Encoding Works

Razor HTML-encodes expressions by default. When you write @Model.Comment, Razor passes the value through an HtmlEncoder that converts characters such as <, >, &, and " into their HTML entities. The browser then displays the literal text instead of parsing it as markup or script. The same protection applies to values rendered inside HTML attributes, because attribute encoding is applied where needed.

Key Protection Points

• Razor expressions: @Model.Name is encoded; never use Html.Raw on untrusted input, since it bypasses encoding entirely.

• Tag helpers: attributes set with tag helpers, such as <a asp-controller="Home" asp-action="Index" asp-route-id="@Model.Id">, encode the values they write.

• JavaScript contexts: encoding rules differ by context. A value injected into a <script> block needs JavaScript encoding, not just HTML encoding. Prefer passing data through data-* attributes or an API call; if you must embed it, use @Json.Serialize (or System.Text.Json), which produces JavaScript-safe output.

• URL data: when building URLs from user input, encode with Url.Encode and validate that the value is a safe relative URL, to avoid javascript: or data: payloads.

• Model validation: attributes such as [StringLength], [RegularExpression], and custom validation attributes reject dangerous input early, before it reaches the view.

Additional Defenses

• Content Security Policy (CSP): a response header that restricts script sources is the strongest second layer. With a policy such as script-src 'self', an injected <script>alert(1)</script> will not run even if encoding fails somewhere.

• HttpOnly cookies: setting the HttpOnly flag on authentication cookies limits the impact of any XSS that does occur, because client-side script cannot read them.

• Encoded output in other layers: data stored in a database and later shown in a desktop or email client may need different encoding; encode for the consuming context, not just the web view.

Comparing Common Approaches

Code Example

The controller validates input and stores it safely; the view encodes it automatically.

using System.ComponentModel.DataAnnotations;

public class CommentViewModel
{
    [Required, StringLength(500)]
    public string Text { get; set; } = string.Empty;
}

public class CommentController : Controller
{
    [HttpPost]
    [ValidateAntiForgeryToken]
    public IActionResult Add(CommentViewModel model)
    {
        if (!ModelState.IsValid)
            return View(model);

        // Persist the raw text; encoding happens at output time.
        return RedirectToAction(nameof(Index));
    }
}

@model CommentViewModel

<!-- Encoded automatically: <script> becomes &lt;script&gt; -->
<div class="comment">@Model.Text</div>

<!-- Pass data to script safely instead of injecting it inline -->
<div id="comment" data-text="@Model.Text"></div>

<script>
    const el = document.getElementById('comment');
    const text = el.dataset.text; // read from the data attribute
</script>

Adding a CSP header globally:

app.Use(async (context, next) =>
{
    context.Response.Headers.ContentSecurityPolicy =
        "default-src 'self'; script-src 'self'";
    await next();
});

Best Practices and Common Pitfalls

• Assume all input is untrusted: query strings, form fields, route values, headers, and database rows that originated from users.

• Never render a raw string that came from a user; if you must render generated HTML, sanitize it with a well-known library and state that sanitization is not a complete guarantee.

• Do not try to block XSS only by filtering <script> in input; encodings such as Unicode or HTML entities can bypass naive filters.

• Test with a payload such as <img src=x onerror=alert(1)> in every field you render, to confirm the encoding is effective.

Core Mechanisms

The [Authorize] attribute restricts access to authenticated users. To limit access by role, pass the role name via the Roles parameter, such as [Authorize(Roles = "Admin")]. Roles function as claims of type http://schemas.microsoft.com/ws/2008/06/identity/claims/role. If a user lacks the required claim, the framework returns a 401 Unauthorized or 403 Forbidden status. The [AllowAnonymous] attribute overrides authorization on specific actions within a secured controller.

Policy-Based Authorization

Policies decouple authorization logic from roles, allowing reusable requirements defined in Program.cs. A policy can combine multiple requirements, such as needing a specific role AND a specific claim. You register policies using AddAuthorization during service configuration. This approach is preferred over hardcoding role strings in controllers because it centralizes security logic and simplifies testing. Policies can also use custom handlers implementing IAuthorizationHandler for database-driven checks.

Filter Execution Order

Authorization filters execute early in the request pipeline to block unauthorized requests before business logic runs. The complete ASP.NET Core filter run order is: authorization, resource, action, exception, result. Because authorization runs first, failed checks prevent model binding and action execution, saving server resources. Exception filters run only if an unhandled exception occurs during later stages. Understanding this order ensures security checks happen before any state changes.

Code Example

The following snippets demonstrate policy registration in Program.cs and usage in a controller.

// Program.cs
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireAdmin", policy =>
        policy.RequireRole("Admin"));
});

// Controllers/AdminController.cs
[Authorize(Policy = "RequireAdmin")]
public class AdminController : Controller
{
    public IActionResult Dashboard() => View();
}

Best Practices and MVC 5 Difference

Always enforce authorization on the server; client-side hiding is insufficient for security. Use policies instead of magic strings for roles to prevent typos and centralize changes. Apply the principle of least privilege by granting only necessary permissions. Classic MVC 5 supports only role-based [Authorize(Roles = "...")] and custom AuthorizeAttribute subclasses registered as global filters in FilterConfig.cs; it has no policy-based authorization or IAuthorizationHandler. Avoid placing sensitive logic in views, and ensure authentication middleware is added before authorization middleware in the pipeline. Unit test authorization handlers separately from controllers.

Authentication

• ASP.NET Core Identity: full membership system with user/role stores, password hashing, lockout, and external logins. Best when the API serves your own users and needs registration and login.

• JWT bearer authentication: standard for stateless APIs and SPAs. The client sends a signed token in the Authorization: Bearer <token> header; the server validates signature, issuer, audience, and lifetime. No server-side session is required.

• Cookie authentication: typical for server-rendered MVC apps. If an API accepts cookies from a browser front-end, CSRF protection becomes mandatory.

• OAuth 2.0 / OpenID Connect: use AddJwtBearer with OIDC discovery for APIs, or AddOpenIdConnect for server-rendered federated sign-in (Azure Entra ID, Google, Keycloak).

Authorization

• [Authorize]: on a controller or action to require an authenticated user; [AllowAnonymous] opts endpoints out.

• Role-based: [Authorize(Roles = "Admin")] checks role claims.

• Policy-based: the recommended approach. Register a named policy with RequireRole, RequireClaim, or a custom IAuthorizationRequirement handler, then use [Authorize(Policy = "AdminOnly")]. Keeps logic declarative and testable.

• Resource-based: implement AuthorizationHandler<TRequirement, TResource> when permission depends on the resource (for example, “users may edit only documents they own”).

Transport, CORS, and Headers

• HTTPS and HSTS: UseHttpsRedirection() forces encrypted transport; UseHsts() tells browsers to remember HTTPS-only. Skip HSTS in development.

• CORS: configure AddCors with a named policy listing allowed origins, methods, and headers. Never leave defaults wide open, and never combine AllowAnyOrigin with credentials.

• Rate limiting: .NET 8 includes Microsoft.AspNetCore.RateLimiting (fixed/sliding window, token bucket, concurrency). Apply globally or per endpoint against brute-force and DoS.

• Security headers: add X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, and Referrer-Policy, manually or via NetEscapades.AspNetCore.SecurityHeaders.

• Secrets: keep keys and connection strings out of source control; use user secrets in development and a managed vault (Azure Key Vault) in production.

Input Validation, Over-Posting, and CSRF

• Model validation: decorate request models with [Required], [StringLength], [Range], [RegularExpression] and check ModelState.IsValid. With [ApiController], an invalid model returns 400 Bad Request automatically.

• Over-posting: never bind an entity class directly from user input. Use a view model or DTO with only settable fields, or restrict binding with [Bind].

• Antiforgery: with cookie auth, the form Tag Helper (<form asp-action="...">) emits the hidden token, and [ValidateAntiForgeryToken] or AutoValidateAntiforgeryTokenAttribute validates it. Bearer tokens are not vulnerable to classic CSRF because browsers do not attach them automatically.

• Parameterized data access: Razor encodes output; always use parameterized queries so input never becomes SQL.

Code Example

Minimal Program.cs wiring JWT bearer auth, a policy, HTTPS redirection, and correct middleware order:

using System.Text;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();

// Validate the bearer token on every request
builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidAudience = builder.Configuration["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]!))
        };
    });

// Named policy reusable from any controller
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("AdminOnly", policy => policy.RequireRole("Admin"));
});

var app = builder.Build();
app.UseHttpsRedirection();   // redirect before auth
app.UseAuthentication();     // who is the caller?
app.UseAuthorization();      // what may the caller do?
app.MapControllers();
app.Run();

Endpoints protected with attributes:

using System.Collections.Generic;
using System.Linq;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

public class Document
{
    public int Id { get; set; }
    public string Title { get; set; } = "";
}

[ApiController]
[Route("api/[controller]")]
public class DocumentsController : ControllerBase
{
    private static readonly List<Document> _store = new();

    // Any authenticated user
    [Authorize]
    [HttpGet("{id:int}")]
    public ActionResult<Document> Get(int id) =>
        Ok(_store.FirstOrDefault(d => d.Id == id));

    // Only users in the Admin role
    [Authorize(Policy = "AdminOnly")]
    [HttpDelete("{id:int}")]
    public IActionResult Delete(int id)
    {
        var doc = _store.FirstOrDefault(d => d.Id == id);
        if (doc is null) return NotFound();
        _store.Remove(doc);
        return NoContent();
    }
}

Best Practices and Common Pitfalls

• Order middleware correctly: UseHttpsRedirection → UseAuthentication → UseAuthorization → endpoint mapping. Auth must run before authorization.

• Fail closed: secure controllers by default with [Authorize] and mark only public actions [AllowAnonymous].

• Do not roll your own crypto: use established libraries and OIDC providers.

• Log and monitor: record authentication failures and authorization denials.

• Classic ASP.NET MVC 5 differs: on .NET Framework 4.8, auth and filters are configured in Startup.Auth.cs / FilterConfig.cs with OWIN; the MVC 5 filter order is authentication, authorization, action, result, exception, versus ASP.NET Core’s authorization, resource, action, exception, result.

How CSRF Works

In a CSRF attack, a victim visits a malicious website while still authenticated on a target site (e.g., a banking portal). The malicious site contains a hidden form or image tag that submits a request to the target site. Because the browser automatically includes cookies (including authentication cookies) with the request, the target site treats the action as legitimate. This allows attackers to perform actions like transferring funds or changing passwords without the user’s consent.

The Antiforgery Token Mechanism

ASP.NET Core mitigates this by requiring a secret token for state-changing operations (POST, PUT, DELETE). The system generates two parts: - Cookie Token: Stored in an HTTP-only cookie sent to the browser. - Form Token: Embedded within the HTML form or sent via a custom header for AJAX requests.

When a POST request arrives, the server validates that both tokens match and were issued by the same application instance. Since malicious sites cannot read the cookie token due to Same-Origin Policy restrictions, they cannot construct a valid request.

Implementation in Views and Controllers

• Views: The Form Tag Helper automatically injects a hidden __RequestVerificationToken input into any form that uses method="post", so you do not need to manually call HTML helpers like Html.BeginForm(), which is the older MVC 5 style.

• Controllers: Decorate action methods that modify data with the [ValidateAntiForgeryToken] attribute so the framework rejects requests missing a valid token.

• Validation flow: If the token is missing or invalid, ASP.NET Core returns a 400 Bad Request before the action body executes, so no state-changing logic runs.

AJAX and Global Validation

For JavaScript-driven requests, you must retrieve the token from the hidden form field or the antiforgery cookie and send it in the request header, typically named RequestVerificationToken. To avoid decorating every action, you can apply the AutoValidateAntiforgeryTokenAttribute globally via filters in Program.cs. This enforces validation on all state-changing methods by default, reducing the risk of human error.

Classic MVC 5 Difference

In classic ASP.NET MVC 5 on .NET Framework, the mechanism is conceptually identical using @Html.AntiForgeryToken() and [ValidateAntiForgeryToken], but configuration relied on Web.config and FilterConfig.cs rather than the dependency injection and middleware pipeline used in ASP.NET Core.

Best Practices and Pitfalls

• Always Use HTTPS: Tokens transmitted over HTTP can be intercepted, compromising security.

• Avoid Disabling Globally: Do not remove antiforgery validation globally unless building a pure API consumed by non-browser clients.

• Combine with Over-Posting Protection: Use view models instead of binding entities directly to prevent attackers from manipulating fields outside the form scope.

• Check ModelState.IsValid: Even with valid tokens, always validate model state before processing data to ensure input integrity.

• SameSite Cookies: Configure authentication cookies with SameSite=Lax or Strict as an additional layer of defense alongside tokens.

Enforcing HTTPS with Middleware

Two middleware components in Program.cs handle most of the work: - UseHttpsRedirection(): returns a 307 redirect to the HTTPS version of the requested URL for any HTTP request. - UseHsts(): adds the Strict-Transport-Security header, telling browsers to only use HTTPS for future requests. It should run only in non-development environments.

The order matters: register these early in the pipeline so they run before other middleware generates a response, and always call UseForwardedHeaders() before UseHttpsRedirection() when behind a proxy. Their position relative to UseRouting() does not affect whether they run.

Configuring the Certificate

• Development: the template uses the ASP.NET Core development certificate. Trust it with dotnet dev-certs https --trust (Windows/macOS; on Linux the browser must be configured manually).

• Production on IIS: bind the purchased or issued certificate to the site in IIS Manager; Kestrel does not need the certificate directly.

• Production on Kestrel/Linux: configure the endpoint in appsettings.json under Kestrel:Endpoints, pointing to a .pfx file. The password must come from User Secrets, environment variables, or a vault, never from source control.

The RequireHttps Attribute

The [RequireHttps] action filter enforces HTTPS at the controller or action level. For GET requests it redirects to HTTPS; for other verbs it returns 403 Forbidden. It is useful for sensitive areas such as login or payment pages, but middleware-based redirection is preferred for site-wide enforcement.

Behind a Reverse Proxy

When the app sits behind IIS, nginx, or a load balancer, the TLS connection terminates at the proxy and the app receives plain HTTP. Call UseForwardedHeaders() early in the pipeline and configure ForwardedHeadersOptions so Request.IsHttps reflects the original request; otherwise redirection and [RequireHttps] will loop or misbehave. By default the middleware only trusts loopback addresses, so in production add KnownProxies or KnownNetworks. This applies to Linux and Windows hosting behind a proxy.

Code Example

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedProto;
    // In production, trust your proxy addresses:
    // options.KnownProxies.Add(IPAddress.Parse("10.0.0.1"));
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseHsts(); // Strict-Transport-Security, production only
}

app.UseForwardedHeaders(); // Read X-Forwarded-Proto from the proxy
app.UseHttpsRedirection(); // 307 HTTP -> HTTPS
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");
app.Run();

// appsettings.json - Kestrel HTTPS endpoint (password from secrets)
{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://*:7001",
        "Certificate": {
          "Path": "certs/server.pfx"
        }
      }
    }
  }
}

// Controller-level enforcement for sensitive actions
[RequireHttps]
public class AccountController : Controller
{
    public IActionResult Login() => View();
}

Best Practices and Common Pitfalls

• HSTS only in production: never send HSTS from a development machine, or browsers will refuse HTTP locally.

• Secure cookies: set CookiePolicyOptions.MinimumSameSitePolicy and use CookieSecurePolicy.Always so session and antiforgery cookies travel only over HTTPS.

• Do not commit secrets: the .pfx password belongs in User Secrets (dotnet user-secrets) or an environment variable, not in appsettings.json.

• Test both schemes: verify that HTTP redirects correctly and that HTTPS URLs generate without mixed-content warnings.

• Classic MVC 5 differs: there is no middleware; you configure the certificate in IIS bindings and enforce HTTPS with [RequireHttps] or a rewrite rule in Web.config.

Authentication Filters

MVC 5 added a fifth filter kind to the pipeline. The full run order in MVC 5 is: authentication, authorization, action, result, with exception filters firing when an earlier stage throws. Before MVC 5, authentication could only be done in Global.asax (Application_AuthenticateRequest) or inside an authorization filter, which made it hard to combine multiple credential schemes.

• IAuthenticationFilter: the new interface. Its OnAuthentication method runs first and can set HttpContext.User or short-circuit the request; its OnAuthenticationChallenge method runs after authorization, receiving an AuthenticationChallengeContext so the filter can issue a challenge (for example a 401 that a cookie or OAuth middleware turns into a login redirect).

• Multiple schemes: because authentication is now a filter, you can stack several of them and let each one handle a different credential type, which the previous single-membership model could not do.

• [AllowAnonymous]: works with the new pipeline so specific actions opt out of authentication without disabling the whole filter.

ASP.NET Identity

The MVC 5 project templates dropped SimpleMembership (and the older SqlMembershipProvider) in favor of ASP.NET Identity, wired up through OWIN middleware in Startup.Auth.cs (app.UseCookieAuthentication(...)).

• Claims-based identity: user identity is expressed as claims (ClaimsIdentity), so you can carry arbitrary user data in the cookie instead of stuffing it into HttpContext.Session.

• UserManager<TUser> / SignInManager<TUser, TKey>: APIs for creating users, validating passwords, signing in with a persistent cookie, and locking out accounts after repeated failures (SignInManager arrived with ASP.NET Identity 2.x).

• Pluggable storage: user data goes to Entity Framework by default (IdentityDbContext), but the stores are interfaces, so you can target another database or service.

• Extensible user model: ApplicationUser : IdentityUser lets you add custom profile properties directly on the user class rather than a separate profile table.

External Authentication (OAuth 2.0 / OpenID)

MVC 5 templates shipped with built-in support for signing in with Google, Facebook, Twitter, and Microsoft accounts, enabled by OWIN security middleware and configured in Startup.Auth.cs. The template’s AccountController stores the external login as a linked IdentityUserLogin, so a local account can be associated with one or more external providers. This replaced the DotNetOpenAuth-based approach used by earlier templates.

CSRF and Request-Forgery Protection

MVC 5 made anti-forgery protection a default part of the generated application rather than something you had to remember to add:

• The generated AccountController POST actions (Login, Register) are decorated with [ValidateAntiForgeryToken], and the matching Razor views call @Html.AntiForgeryToken() inside the form.

• The token is per-session and tied to the user’s claims, so it blocks cross-site request forgery even for authenticated users. (In ASP.NET Core the equivalent is the form tag helper’s automatic token plus [ValidateAntiForgeryToken] or AutoValidateAntiforgeryToken.)

Comparison: Old vs. New in MVC 5

Best Practices and Caveats

• Keep [ValidateAntiForgeryToken] on every state-changing POST action; a missing token is one of the most common CSRF gaps in MVC 5 apps.

• Do not put ValidateAntiForgeryToken on GET actions — it is meaningless there and breaks linked URLs.

• If you are starting new work, build on ASP.NET Core: MVC 5 and ASP.NET Identity 2.x receive only security fixes, and features such as two-factor authentication, external providers, and policy-based authorization are far more capable in the current stack.

How It Works

Browsers block JavaScript on https://frontend.example from calling an API on https://api.example unless the API sends CORS response headers that explicitly allow the origin. ASP.NET Core handles this with:

• Service registration: builder.Services.AddCors() adds ICorsService and ICorsPolicyProvider to the container.

• Policies: a named policy is a set of allowed origins, methods, headers, exposed response headers, credentials settings and a preflight cache duration.

• Middleware: app.UseCors() inspects the Origin request header and, if a matching policy allows it, adds Access-Control-Allow-Origin and related headers to the response.

• Preflight: for non-simple requests the browser first sends an OPTIONS request; the CORS middleware intercepts it and returns the allowed methods and headers without reaching your action.

Configuring CORS

Define policies at startup. A named policy is applied where needed; a default policy is used by app.UseCors() with no argument and by endpoints that require CORS without a policy name.

• WithOrigins(...): the only safe option for production — list the exact origins.

• AllowAnyOrigin, AllowAnyMethod, AllowAnyHeader: fine for development, risky in production.

• AllowCredentials: allows cookies and Windows authentication; it cannot be combined with AllowAnyOrigin (the framework rejects that combination), so use WithOrigins with it.

• SetPreflightMaxAge: how long the browser may cache preflight results.

• WithOrigins("https://*.example.com") together with SetIsOriginAllowedToAllowWildcardSubdomains(): wildcard subdomain support.

Middleware order matters: place app.UseCors() after app.UseRouting() and before app.UseAuthorization() and endpoint mapping, so the policy is evaluated for the selected endpoint.

Controlling CORS per Controller or Action

• [EnableCors("PolicyName")] on a controller or action overrides the middleware policy for that endpoint.

• [DisableCors] excludes a specific action even when a global policy is configured.

• With endpoint routing you can also call RequireCors("PolicyName") on a route group built with MapControllerRoute or controller route conventions.

In classic ASP.NET MVC 5 / Web API on .NET Framework 4.8, CORS is configured differently: you install Microsoft.AspNet.WebApi.Cors, call config.EnableCors(new EnableCorsAttribute(...)) in WebApiConfig and decorate controllers with [EnableCors] from the System.Web.Http.Cors namespace.

Code Example

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();

builder.Services.AddCors(options =>
{
    // Named policy for the browser front-end
    options.AddPolicy("AllowFrontend", policy =>
    {
        policy.WithOrigins("https://www.contoso.com", "https://admin.contoso.com")
              .AllowAnyHeader()
              .AllowAnyMethod()
              .AllowCredentials()
              .SetPreflightMaxAge(TimeSpan.FromSeconds(120));
    });

    // Default policy used by app.UseCors() without an argument
    options.AddDefaultPolicy(policy =>
    {
        policy.WithOrigins("https://www.contoso.com")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

var app = builder.Build();

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();
app.UseCors("AllowFrontend");   // after UseRouting, before UseAuthorization
app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

using Microsoft.AspNetCore.Cors;
using Microsoft.AspNetCore.Mvc;

[EnableCors("AllowFrontend")]          // applies to every action in the controller
public class DataController : Controller
{
    public IActionResult Index() => View();

    [DisableCors]                      // this action never allows cross-origin calls
    public IActionResult Internal() => Ok();
}

Best Practices and Common Pitfalls

• Never use AllowAnyOrigin in production: it lets any site call your API from a user’s browser; restrict to known origins.

• Do not combine AllowCredentials with AllowAnyOrigin: the CORS service throws when it evaluates the policy for a cross-origin request; specify origins explicitly instead.

• Check the middleware order: UseCors before UseRouting means no endpoint is selected yet and the policy may not be applied as expected.

• CORS is a browser-enforced mechanism, not a security boundary: a non-browser client ignores the headers entirely, so keep authentication and authorization checks in place.

• Preflight failures look like 405 or missing headers: verify the requested method and headers are covered by the policy and that OPTIONS is not blocked by other middleware.

How SQL Injection Occurs

• An attacker submits malicious SQL through a form field, query string, or header value.

• If the application builds a query by concatenating that input into a SQL string, the injected text becomes part of the command the database executes.

• Consequences range from unauthorized data reads to data modification, deletion, or even remote code execution on the database server.

Why Parameterized Queries Work

• The query structure is sent to the database separately from the parameter values.

• The database compiles the statement plan first, then binds the values as data.

• Special characters like quotes or semicolons in the input cannot alter the query logic.

• This applies whether you use Entity Framework Core, Dapper, or raw ADO.NET with typed SqlParameter.

Entity Framework Core Protection

• LINQ queries are automatically parameterized, so Where(u => u.Username == username) is safe by default.

• For raw SQL, FromSqlInterpolated turns each interpolation into a parameter; use it when you do not need to specify exact SQL types.

• When you need explicit control (e.g., varchar(100)), use FromSqlRaw with SqlParameter objects that declare SqlDbType and size.

• Avoid FromSqlRaw with string concatenation; stored procedures are not a magic fix either—concatenated arguments passed to them remain vulnerable.

Code Example

// Safe: LINQ is parameterized automatically
public async Task<User> GetUserAsync(string username)
{
    return await _context.Users
        .FirstOrDefaultAsync(u => u.Username == username);
}

// Safe: raw SQL with explicit SqlDbType and size
public async Task<List<Product>> SearchAsync(string term)
{
    var termParameter = new SqlParameter("@term", SqlDbType.VarChar, 100) { Value = term };
    return await _context.Products
        .FromSqlRaw("SELECT * FROM Products WHERE Name LIKE @term", termParameter)
        .ToListAsync();
}

// Safe: Dapper with explicit DbType and size
public async Task<User> GetUserDapperAsync(string username)
{
    var parameters = new DynamicParameters();
    parameters.Add("@Username", username, DbType.String, ParameterDirection.Input, 100);
    return await _connection.QueryFirstOrDefaultAsync<User>(
        "SELECT * FROM Users WHERE Username = @Username",
        parameters);
}

Additional Hardening Measures

• Validate input: use data annotations and check ModelState.IsValid before using any input, even though validation alone does not stop injection.

• Least privilege: the database account used by the app should have only the permissions it needs, limiting damage if a vulnerability is found.

• Avoid dynamic SQL: do not build table names, column names, or ORDER BY clauses from user input; whitelist allowed values instead.

• Keep dependencies updated: EF Core, Dapper, and database drivers receive security patches regularly.

• Review raw queries: treat any FromSqlRaw, ExecuteSqlRaw, or string-built query as a security-sensitive code path during review.

In classic ASP.NET MVC 5 on .NET Framework 4.8, the mechanism is identical in principle but uses ADO.NET directly: create a SqlCommand, add typed SqlParameter objects (specifying SqlDbType and size), and never concatenate input into CommandText.

Request Pipeline and Filter Execution

The request flow proceeds through routing, controller and action selection, model binding, model validation, filters, action result, and finally view rendering. Filters execute in a specific order: authorization, resource, action, exception, and result. To tune performance, keep filter logic minimal; heavy computations in authorization or resource filters delay every request. Model validation should rely on data annotations, checking ModelState.IsValid early to fail fast, though [ApiController] automatically returns 400 for invalid models. Minimizing work in the pipeline ensures faster response times.

Caching and Compression

Caching reduces database load and computation time significantly. Use the [ResponseCache] attribute on actions to store output in the client or proxy cache, setting Location to Client or Any. Cache profiles can be defined centrally in startup configuration to avoid repeating attributes across actions. For server-side data, inject IMemoryCache or use distributed caching for multi-server setups to avoid redundant queries. Enable response compression middleware to shrink payload sizes for JSON and HTML responses. Static files should be served via the static files middleware with appropriate cache headers configured to leverage browser caching effectively.

Asynchronous Programming and Data Access

Controllers should use async Task<IActionResult> signatures to free thread pool threads during I/O operations like database calls or HTTP requests. Never block async code with .Result or .Wait(), as this wastes thread pool threads and can cause thread starvation under load. When querying with Entity Framework Core, use AsNoTracking() for read-only operations and project results directly to view models to prevent over-fetching columns. This also supports security by preventing over-posting, as you bind only necessary fields rather than full entities.

Common Pitfalls

Avoid mixing synchronous and asynchronous code paths, which negates scalability benefits and risks thread pool exhaustion. Do not store large objects in TempData (which is serialized) or ViewBag, as this increases memory usage per request. Ensure view models are lean; binding large entity classes directly increases model binding costs and security risks. Finally, profile using tools like Application Insights or dotTrace before optimizing, as bottlenecks often lie in database queries rather than C# code, specifically N+1 query patterns.

Measure First

Never optimize blind. Use browser DevTools (Network and Performance tabs) to see request sizes, waterfall timing, and blocking scripts, and use Application Insights, OpenTelemetry, or dotnet-counters on the server to find slow database queries and high allocations. A page that looks slow because of a 3 MB image needs a completely different fix from one that is slow because of a 400 ms SQL query.

Server-Side Optimizations

• Async actions: return Task<IActionResult> and await I/O so thread pool threads are released instead of blocking.

• Response compression: enable Brotli and Gzip (the default MinimumResponseLength is 2048 bytes, so smaller responses are skipped); set EnableForHttps = true to compress HTTPS responses.

• Response caching: [ResponseCache] plus AddResponseCaching()/UseResponseCaching() stores HTTP responses, respecting Cache-Control semantics.

• Output caching: [OutputCache] (server-side caching introduced in .NET 7) caches generated content regardless of client cache headers, with cache profiles and tag helpers for invalidation.

• Reduce allocations: avoid large LINQ projections into entity graphs, reuse HttpClient through IHttpClientFactory, and stream large responses instead of buffering them.

Database and Data Access

• AsNoTracking() for read-only queries skips change tracking and is measurably faster.

• Project to a view model with Select() so you fetch columns you actually render instead of whole entities — this also prevents over-posting.

• N+1 queries: eager-load only the navigation properties the view needs with Include, and profile with Microsoft.EntityFrameworkCore logging.

• Cache stable lookup data in IMemoryCache (single server) or IDistributedCache with Redis (multiple instances).

Client-Side and Static Assets

• Bundling and minification: in ASP.NET Core use the WebOptimizer NuGet package or build-time tools; set long Cache-Control headers via StaticFileOptions.OnPrepareResponse (or a CDN) and use cache-busting via asp-append-version="true" on the script and link tag helpers.

• CDN: serve libraries such as jQuery or Bootstrap from a CDN with a local fallback.

• Render-blocking resources: put scripts at the end of the body or use defer, and inline critical CSS for above-the-fold content.

• Images: serve WebP/AVIF, size them to the viewport, and lazy-load below-the-fold images with loading="lazy".

• In classic MVC 5 the equivalent of bundling is BundleConfig in App_Start with System.Web.Optimization and @Scripts.Render; also, Html.Action child actions used for reusable widgets do not exist in ASP.NET Core — use view components instead, which render asynchronously.

Best Practices and Common Pitfalls

• Do not cache personalized or sensitive data without Location=Client or varying by user; a shared cache can leak one user’s data to another.

• Compression and caching middleware order matters: register compression before UseStaticFiles so cached entries are stored already compressed.

• Do not over-cache: a short Duration with VaryByQueryKeys is safer than caching an entire action for hours when data changes often; use [OutputCache] with tag-helper invalidation when you need explicit control.

• Avoid synchronous-over-async calls such as .Result on async methods; they cause thread pool starvation that shows up as random latency spikes under load.

• Keep the view model small: rendering a huge entity graph and then hiding fields in Razor still ships them from the database.

How It Works

When a request arrives, the caching middleware checks whether a stored response exists for the request key. If it does, the stored response is written back and the rest of the pipeline — routing to the controller, action selection, model binding, model validation, filters and view rendering — is short-circuited. If not, the request proceeds and the middleware stores a copy of the response before it leaves the server.

• Response caching (UseResponseCaching + [ResponseCache]) adds HTTP cache headers and caches on the client, on proxies, or on the server, following Cache-Control directives. It only caches GET/HEAD responses with a 200 status and ignores requests with an Authorization header.

• Output caching (AddOutputCache + UseOutputCache + [OutputCache]) always caches on your own server, so it works even when clients send no-cache and even for authenticated requests, provided you vary the cache key by claim.

Response Caching vs Output Caching

Code Example

Register the service, add the middleware once in the pipeline, then decorate actions. Middleware order matters: UseOutputCache goes after UseRouting and before endpoint execution.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();
builder.Services.AddOutputCache(options =>
{
    options.AddPolicy("Products", builder => builder
        .Expire(TimeSpan.FromMinutes(5))
        .SetVaryByQueryKeys(new[] { "page", "q" })  // separate cache per page/query
        .SetVaryByClaims("UserId"));                // per-user entries
});

var app = builder.Build();

app.UseRouting();
app.UseOutputCache();   // after routing, before endpoints
app.MapDefaultControllerRoute();

app.Run();

public class ProductsController : Controller
{
    // Anonymous, public data: safe to share across users.
    [OutputCache(Duration = 60)]
    public IActionResult Index()
    {
        var products = new List<string> { "Widget", "Gadget" }; // from the data layer
        return View(products);
    }

    // Personalised data: vary by the UserId claim so users never see each other's data.
    [OutputCache(PolicyName = "Products")]
    public IActionResult Mine()
    {
        var products = new List<string> { "My Widget" }; // from the data layer, filtered by user
        return View(products);
    }
}

Duration, VaryByQueryKeys, VaryByHeader, VaryByRouteValues and VaryByClaims can be set either on the attribute or, preferably for consistency, in a named policy registered in Program.cs.

Best Practices and Pitfalls

• Never cache personalised content without varying by user. Use VaryByClaims or skip caching; otherwise one user’s data leaks to another.

• Do not cache POST, PUT or DELETE responses. Output caching applies to safe GET/HEAD requests by default.

• Cache only stable, read-only data. Anything derived from TempData, the current time or non-deterministic state produces stale or wrong results.

• Keep cache durations short enough that data changes propagate; use cache tags or a revalidation strategy for long-running entries.

• Do not mix the two middlewares for the same action. Pick output caching when you need server-side control, response caching when clients and CDNs should do the work.

• Be careful with antiforgery tokens in cached views. The token is part of the rendered response, so a cached page replays the same token to every user. For forms on cached pages, fetch the token separately through the IAntiforgery service (for example from a small dedicated endpoint) or exclude those actions from caching.

Classic ASP.NET MVC 5

In MVC 5 on .NET Framework 4.8 there is no middleware: caching is applied with [OutputCache] from System.Web.Mvc, configured through the <outputCache> and <caching> sections of web.config, and backed by System.Web.Caching. The [ResponseCache] attribute and the output-caching middleware described above do not exist in that stack.

Short-Lived Request State

Data passed from controllers to views typically exists only for the current HTTP request. ViewData is a dictionary of objects, while ViewBag is a dynamic wrapper around ViewData; both are discarded after the view renders. TempData differs by surviving one additional request, usually a redirect, and is automatically cleared once read. This makes TempData ideal for flash messages without persisting data unnecessarily. In classic MVC 5, TempData relied solely on session state, whereas ASP.NET Core allows cookie-based providers.

Persistent State and Caching

For data needing persistence across multiple requests, Session stores user-specific values server-side but consumes server memory. To enhance performance, expensive data retrieval should use caching instead of repeated database queries. IMemoryCache stores data in-process for single-server scenarios, while IDistributedCache (e.g., Redis) supports scaled-out environments. Caching reduces latency by serving data from fast memory rather than slower storage systems.

Best Practices and Pitfalls

Avoid storing large objects in Session to prevent memory bloat and scaling issues. Prefer view models over ViewBag for strong typing and compile-time safety, which reduces runtime reflection overhead. Use sliding or absolute expiration on cache entries to ensure stale data is refreshed automatically. Remember that TempData relies on session state or cookie providers in ASP.NET Core, so configure the appropriate provider in Program.cs. Additionally, consider using the [ResponseCache] filter to cache entire action outputs at the client or proxy level. Do not cache sensitive user data without encryption, and always validate cache keys to prevent injection issues. In classic MVC 5, session configuration occurred in Web.config rather than code.

How Async Actions Work

To create an async action, add the async keyword to the method signature and return a Task<IActionResult> instead of IActionResult. Inside the method, use the await keyword when calling asynchronous dependencies, such as database queries via Entity Framework Core or external HTTP calls using HttpClient. The compiler generates a state machine that suspends execution at the await point without blocking the underlying thread, resuming once the awaited task completes.

Performance Benefits

Async actions are primarily beneficial for I/O-bound workloads rather than CPU-bound computations. When a thread waits for a database response or file system access synchronously, it remains occupied and cannot serve other requests. By awaiting these operations, the thread returns to the thread pool, increasing throughput under high concurrency. This is critical for scalable web APIs and web applications where many requests may be waiting on external resources simultaneously.

Request Flow Context

Asynchronous actions fit into the standard ASP.NET Core request pipeline after routing and controller selection. The flow proceeds from routing to controller and action selection, followed by model binding and model validation. Filters (authorization, resource, action, exception, result) execute around the action invocation. When the action is async, the pipeline awaits the returned task before proceeding to action result execution and view rendering. The async nature does not change the order of filters or validation logic.

Code Example

public class ProductsController : Controller
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
    }

    public async Task<IActionResult> Details(int id)
    {
        // Await the I/O-bound service call without blocking the thread
        var product = await _productService.GetByIdAsync(id);

        if (product == null)
        {
            return NotFound();
        }

        return View(product);
    }
}

In this example, Details awaits GetByIdAsync. If the service uses Entity Framework Core, the database query runs asynchronously. The controller inherits from Controller, and dependency injection provides the service instance.

Best Practices and Pitfalls

• Avoid async void: Never use async void for action methods; exceptions cannot be caught properly and the request may complete prematurely.

• Do not block: Avoid calling .Result or .Wait() on tasks, as this can cause deadlocks in the synchronization context.

• ConfigureAwait: Use ConfigureAwait(false) in library code, though it is less critical within controller actions themselves.

• Overhead: Do not use async for trivial CPU-bound work; the state machine overhead may outweigh benefits.

• MVC 5 Difference: Classic ASP.NET MVC 5 also supports async Task<ActionResult>, but older versions relied on the legacy AsyncController class which is not used in ASP.NET Core.

How It Works

On every request the middleware runs a short negotiation:

1. The client advertises algorithms with Accept-Encoding: br, gzip; browsers send this automatically.

2. The middleware scans the registered providers in registration order and selects the first one whose encoding the client accepts.

3. If the response content type is in the configured MIME list, no Content-Encoding header is already present, and the body is at least MinimumResponseBytesLength bytes, the middleware buffers the body, compresses it, and writes Content-Encoding.

4. If the client sends no Accept-Encoding, the content type is not listed, or the status code has no compressible body (for example 204, 205, 304), the response passes through unchanged.

Responses that already carry Content-Encoding — such as pre-compressed images or files — are never re-encoded.

Built-In Compression Providers

Each provider is tuned through its own options class. BrotliCompressionProviderOptions.Level accepts CompressionLevel.Fastest, Optimal (the default), and NoCompression; it does not support SmallestSize. GzipCompressionProviderOptions.Level uses System.IO.Compression.CompressionLevel directly, so all values including SmallestSize are valid.

What Gets Compressed

Only content types listed in ResponseCompressionOptions.MimeTypes are compressed. The default list is text-centric: text/html, text/plain, text/css, application/javascript, text/javascript, application/json, application/xml, text/xml, and image/svg+xml. Matching is exact, so a response with application/json; charset=utf-8 does not match the default application/json entry unless that exact string is added. There is no ExcludedMimeTypes collection; to stop a type from being compressed, remove it from MimeTypes.

Already-compressed binary formats such as PNG, JPEG, MP4, and ZIP are excluded deliberately: compressing them wastes CPU and can enlarge the payload.

Two behaviors deserve special attention:

• HTTPS is not compressed by default. EnableForHttps is false because compression over TLS can leak information through BREACH or CRIME-style attacks. Enable it only when the response does not reflect user input, or after applying mitigations such as random padding.

• Middleware order is critical. UseResponseCompression() must be registered before UseStaticFiles(), UseRouting(), and endpoint mappings; otherwise the response body is already written and cannot be compressed.

Best Practices and Common Pitfalls

• Place the middleware early. The most common reason compression silently does nothing is registering UseResponseCompression() after static files or endpoint routing.

• Do not compress large binary assets. Keep images, videos, and archives out of MimeTypes; the CPU cost outweighs any size reduction.

• Prefer Brotli for text. It is registered by default and typically reduces text payloads 15–20% more than Gzip at comparable speed.

• Pre-compress static files when practical. Serving a pre-compressed .br or .gz variant from disk avoids recompressing on every request.

• Do not confuse compression with [ResponseCache]. [ResponseCache] sets caching headers and works with the response caching middleware; it does not compress payloads.

• Verify with response headers. A working setup returns Content-Encoding: br or gzip and a smaller payload; check the browser network tab rather than assuming.

• Classic MVC 5 note: ASP.NET MVC 5 on .NET Framework 4.8 has no middleware pipeline. Dynamic and static compression are enabled in IIS through Web.config (<urlCompression doDynamicCompression="true" doStaticCompression="true"/> and <httpCompression>), or implemented manually with a custom action filter.

Caching Layers and HTTP Headers

Response caching operates at two levels: client-side (browser or proxy) via HTTP headers like Cache-Control, and server-side via in-memory stores. The [ResponseCache] attribute primarily sets headers to instruct clients how long to hold a response, while the Output Cache middleware stores the actual response body on the server to bypass action execution entirely. Understanding this distinction is vital for choosing the right strategy based on whether you want to save bandwidth or server processing time.

Implementation Approaches

You can apply caching declaratively on actions or controllers using attributes, or globally via middleware configuration. For granular control, decorate actions with [ResponseCache(Duration = 60)] to set client-side expiry. For broader server-side caching in .NET 8, register AddOutputCache() in services and call UseOutputCache() in the pipeline, then apply [OutputCache] attributes. Classic ASP.NET MVC 5 differs by relying on the [OutputCache] attribute alone, which combines header and server-side caching without the modern middleware pipeline; it has no separate [ResponseCache] attribute.

Position in the Request Flow

The two mechanisms sit at different points. The Output Cache middleware is registered after UseRouting() and, on a cache hit, short-circuits the pipeline before controller selection, model binding, and action execution, returning the stored response directly. The [ResponseCache] attribute is a result filter, so it runs after the action executes and the result is determined but before the response is written, adding Cache-Control and related headers. The ASP.NET Core filter run order is authorization, resource, action, exception, and result filters, with [ResponseCache] operating in the result phase.

Code Example

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOutputCache(); // Enables server-side caching infrastructure
builder.Services.AddControllersWithViews();

var app = builder.Build();
app.UseRouting();
app.UseOutputCache(); // Must be placed after UseRouting
app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");
app.Run();

// HomeController.cs
public class HomeController : Controller
{
    [ResponseCache(Duration = 60, VaryByQueryKeys = new[] { "id" })]
    public IActionResult Details(int id)
    {
        var model = GetData(id);
        return View(model);
    }
}

Best Practices and Security

Never cache responses containing personal or sensitive data, as headers may expose them to shared proxies or other users. Use VaryByHeader or VaryByQueryKeys to create distinct cache entries for different parameters, preventing users from seeing each other’s data due to cache collisions. Always set appropriate durations to balance freshness with performance, and remember that [ApiController] validation errors return 400 automatically regardless of cache settings, so error responses should generally not be cached.

Prerequisites and the Hosting Bundle

Install the .NET 8 Hosting Bundle on the server. It bundles the .NET Runtime, the ASP.NET Core Runtime, and ANCM v2, and it registers the native module with IIS. Without it, IIS has no handler for ASP.NET Core requests. Enable the IIS Windows features you need: IIS Management Console (under Web Management Tools) and World Wide Web Services with the Application Development Features. The classic ASP.NET Windows feature belongs to .NET Framework 4.x applications and is not required for ASP.NET Core. After installing the bundle, restart IIS from an administrator shell (net stop was /y && net start w3svc) so the module is picked up.

Publishing the Application

Compile and package the app with the .NET CLI from the project directory. A framework-dependent deployment is the norm when the Hosting Bundle is already installed, because it keeps the payload small:

dotnet publish -c Release -o ./publish

This produces the app DLLs, appsettings.json, the web.config file, and all dependencies in ./publish. When the server cannot have the runtime installed, publish self-contained with -r win-x64 --self-contained true; this enlarges the deployment considerably, so use it only when necessary.

Configuring the IIS Site and Application Pool

In IIS Manager, create a website whose physical path points at the published folder, and give its application pool a dedicated name. Set the pool’s .NET CLR Version to No Managed Code — ASP.NET Core is driven by ANCM, not by the .NET Framework CLR, so loading a managed runtime into w3wp.exe is unnecessary. Leave the identity as ApplicationPoolIdentity and grant that account Read and Execute permissions on the published folder; missing permissions usually surface as HTTP 500.19, while a failing app start surfaces as 500.30. Choose the hosting model in web.config: in-process (the .NET 8 default) runs the app inside w3wp.exe for the best performance, while out-of-process runs Kestrel in a separate process that ANCM proxies to over a loopback address, giving process-level isolation.

Code Example

The generated web.config is what wires IIS to ANCM. The key element is:

<aspNetCore processPath="dotnet"
            arguments="MyApp.dll"
            stdoutLogEnabled="false"
            stdoutLogFile=".\logs\stdout"
            hostingModel="inprocess" />

• processPath / arguments: how ANCM launches the app (dotnet MyApp.dll); for a self-contained publish, processPath points at the app’s own executable.

• hostingModel: inprocess (default) or outofprocess.

• stdoutLogEnabled: enable temporarily to capture startup failures into .\logs\stdout (the folder must exist); keep it false in production.

Classic MVC 5 Difference

In classic ASP.NET MVC 5 on .NET Framework 4.8, there is no Hosting Bundle or ANCM: the application runs directly inside w3wp.exe using the installed .NET Framework, so the application pool is set to the .NET 4.x CLR version with Integrated pipeline mode rather than No Managed Code, and deployment is mainly an XCOPY of the compiled site plus bin contents.

Common Pitfalls and Security

• HTTPS: serve the site over HTTPS and redirect HTTP with URL Rewrite rules in web.config; never rely on plain HTTP for production.

• Logging: leave stdoutLogEnabled off in production — verbose stdout logging can fill the disk quickly.

• Secrets: keep connection strings and keys out of committed appsettings.json; override them with environment variables, transformed config, or a secure vault.

• Patching: keep the Hosting Bundle updated so the runtime and ANCM receive security fixes.

• Environment: set ASPNETCORE_ENVIRONMENT to Production (for example via the environmentVariables section of aspNetCore in web.config) so production-specific configuration and error pages apply.

How It Works

• Base file: The project contains a single web.config with the default settings used across environments.

• Transform files: Alongside it sit files such as web.Debug.config and web.Release.config, one per build configuration.

• Merge step: When you build or publish with a selected configuration, the build engine applies the matching transform file to the base web.config using XDT syntax, producing the final deployed file.

• Result: Connection strings, API endpoints, and feature flags can differ between local development, staging, and production without changing source code.

Transformation Syntax (XDT)

• xdt:Transform: Declares the operation to perform on a node, such as SetAttributes to change attribute values, Replace to swap an entire element, Insert to add a new node, or Remove to delete one.

• xdt:Locator: Identifies which node the transform applies to, for example MatchAttributes(name) to find a connection string by its name attribute.

• Example behavior: A SetAttributes transform on a <connectionStrings> element updates only the specified attributes while leaving the rest of the file untouched.

How ASP.NET Core Differs

ASP.NET Core does not transform web.config; it builds configuration from a hierarchy of providers. Shared settings live in appsettings.json and environment overrides in appsettings.{Environment}.json, with the active environment selected by the ASPNETCORE_ENVIRONMENT variable. Environment variables, command-line arguments, and secret stores such as Azure Key Vault can override JSON files, so no XML merge step is required.

Security and Secrets Management

• MVC 5: Encrypt sensitive sections such as connectionStrings using the ASP.NET IIS Registration Tool (aspnet_regiis.exe), a legacy tool that remains available in .NET Framework 4.8.

• ASP.NET Core: Use the Secret Manager tool for development and Azure Key Vault or AWS Secrets Manager for production; never commit secrets to source control.

• Priority: The ASP.NET Core configuration system automatically prioritizes environment variables over JSON files, enabling secure injection in containers and cloud deployments.

Best Practices and Common Pitfalls

• Avoid Manual Edits: Never edit configuration files directly on the server; deploy transformed or environment-specific files to prevent configuration drift.

• Validate Transforms: Run the publish process locally and inspect the resulting web.config to confirm expected values before deploying to production.

• Match Build Configuration: Ensure the publish profile uses the intended configuration (Release vs. Debug) so the correct transform file is applied.

• Protect web.config: In MVC 5, rely on IIS rules that deny direct HTTP access to web.config so connection strings are never exposed.

• Test Each Environment: Verify transformed values for every target environment, since a transform that succeeds XML-wise can still write an incorrect value.

What an Application Pool Provides

• Process isolation: Each pool gets its own worker process (w3wp.exe). A crash, memory leak, or hang in one pool cannot take down sites in other pools. This is the main reason to give each important application its own pool.

• Identity and security: The pool runs under an account (the default is the built-in ApplicationPoolIdentity, a least-privilege virtual account). That account is the process’s Windows security context, so it determines what files, registry keys, and network resources the app can read or write. Grant the pool identity write access only to the folders that need it.

• .NET runtime selection: On .NET Framework, the pool is bound to one CLR version (v2.0 or v4.0) and one pipeline mode; a pool cannot host apps needing different runtimes.

• Resource limits and recycling: Queue length, CPU limits, private memory limits, regular time-based recycling, and idle timeouts are all configured per pool.

Integrated vs Classic Pipeline Mode

For MVC 5 on .NET Framework 4.8, the pool should be set to Integrated managed pipeline mode. Integrated mode runs managed modules and handlers directly in the IIS request pipeline, which is what System.Web routing and the MVC UrlRoutingModule rely on. Classic mode runs managed code through an ISAPI bridge, which breaks extensionless routing unless you register extra handlers; it is a legacy setting and should not be used for MVC 5. Also set the pool’s .NET Framework version to v4.0 (which covers 4.8).

Application Pools and ASP.NET Core

ASP.NET Core MVC on .NET 8 is hosted differently on IIS, and this changes what the pool actually does. The default hosting model on IIS is in-process (the app runs inside w3wp.exe, loaded by the ASP.NET Core Module v2); out-of-process hosting runs the app in a separate Kestrel process with IIS acting as a reverse proxy.

Setting the pool to No Managed Code is the single most common IIS misconfiguration for ASP.NET Core: loading the .NET Framework CLR into the worker process is unnecessary and can cause startup failures. This applies to both in-process and out-of-process hosting.

Key Settings to Get Right

• Identity: prefer ApplicationPoolIdentity or a dedicated domain account over Network Service or LocalSystem, which are over-privileged.

• Idle time-out: default is 20 minutes of inactivity before the worker process is killed. For an MVC 5 app or ASP.NET Core in-process this causes a slow first request afterwards; for ASP.NET Core out-of-process hosting it stops the proxy w3wp.exe but not the Kestrel process. Set to 0 to disable when constant responsiveness matters.

• Recycling: periodic recycling (default 29 hours) restarts the worker process, which clears in-memory state such as in-proc session, TempData providers that rely on session, caches, and SignalR connections. Schedule recycling during off-peak hours or move state out of process.

• Queue length and CPU limits: protect a busy server from a single slow app exhausting threads; tune per workload.

• Enable 32-bit: only needed for legacy x86 dependencies; leave disabled for a 64-bit MVC 5 or ASP.NET Core app.

• Auto-start and preload enabled: warm the site after recycling or reboots to avoid a cold first request.

Best Practices and Common Pitfalls

• Give each application its own pool so that recycling, identity, and failures are scoped to that app only; sharing pools couples unrelated apps’ lifecycles.

• Never grant the pool identity full control of the site directory just to fix a permissions error; grant the minimum (typically read, plus write only to App_Data, uploads, or logs).

• Remember that recycling wipes in-memory state: design for it or use a distributed cache and out-of-proc session.

• A pool’s v4.0 CLR setting covers .NET Framework 4.8, but it does not cover .NET (Core) 5+ at all — .NET 8 apps need “No Managed Code” plus the ASP.NET Core Module v2.

How Error Handling Works

ASP.NET Core processes errors through the middleware pipeline before they reach the controller or after a response status is determined. There are two distinct scenarios to cover. First, unhandled exceptions thrown during execution are caught by UseExceptionHandler, which clears the response and re-executes a specified path. Second, valid requests that result in error status codes like 404 Not Found or 500 Internal Server Error do not throw exceptions; these are handled by UseStatusCodePages, which can re-execute a path with the status code attached.

Configuring the Pipeline

In .NET 8, middleware is registered in Program.cs. Exception handling should typically be enabled only in non-development environments so that the developer exception page remains visible during debugging. Status code pages are usually enabled globally. The error endpoint should be marked with [AllowAnonymous] to prevent authentication challenges from interfering with the error response, which could otherwise cause a redirect loop. Place UseStatusCodePagesWithReExecute after UseRouting so that routing has already selected the endpoint, and after UseHttpsRedirection if you want HTTPS to be enforced before error pages are shown.

Classic MVC 5 Difference

In classic ASP.NET MVC 5 on .NET Framework 4.8, custom errors are configured declaratively in Web.config using the <customErrors> element with mode="On", and the HandleErrorAttribute is registered globally in FilterConfig. ASP.NET Core replaces this XML configuration and filter-based approach with code-based middleware, which offers better performance and testability.

Code Example

The following setup configures the middleware, a controller action that captures diagnostic information, and a strongly-typed view.

// Program.cs
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();

app.UseStatusCodePagesWithReExecute("/Error?statusCode={0}");

app.UseAuthorization();
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

// Controllers/ErrorController.cs
using System.Diagnostics;
using Microsoft.AspNetCore.Mvc;

public class ErrorViewModel
{
    public string? RequestId { get; set; }
    public int? StatusCode { get; set; }
}

[AllowAnonymous]
public class ErrorController : Controller
{
    public IActionResult Error(int? statusCode)
    {
        var model = new ErrorViewModel
        {
            RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier,
            StatusCode = statusCode
        };
        // Preserve the original status code (e.g., 404, 500) instead of returning 200
        Response.StatusCode = statusCode ?? 500;
        return View(model);
    }
}

<!-- Views/Shared/Error.cshtml -->
@model ErrorViewModel
<h1>Error</h1>
@if (Model.StatusCode.HasValue)
{
    <p>Status code: @Model.StatusCode</p>
}
<p>Request ID: <code>@Model.RequestId</code></p>

Best Practices

• Do not leak details: Never render exception messages or stack traces in production; UseExceptionHandler excludes these by default outside development.

• Preserve status codes: When re-executing for status pages, set Response.StatusCode in the error action so the final response retains the original code (e.g., 404) rather than returning 200.

• Log errors: Use the logging framework inside a custom IExceptionHandler (available in .NET 8) if you need centralized logging before rendering the page.

• Avoid TempData for errors: Since UseStatusCodePagesWithReExecute re-executes within the same request, pass data via a view model; TempData is only needed if you explicitly redirect.

Health Checks Middleware

The health check system runs registered checks sequentially when a request hits the configured endpoint. In the request flow, routing matches the health endpoint first, then the health check middleware executes directly, without controller selection, model binding, or filters. Each check returns a HealthStatus value: Healthy, Degraded, or Unhealthy. The endpoint responds with HTTP 200 when all checks are Healthy and HTTP 503 when any check is Unhealthy, so load balancers and orchestrators can act on the status code alone. It is designed to be lightweight so that monitoring traffic does not impact normal user request performance.

Configuration Steps

To enable health checks, register the services in Program.cs and map the endpoint in the middleware pipeline. You call AddHealthChecks on the service collection and MapHealthChecks after routing is configured.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHealthChecks();

var app = builder.Build();
app.MapControllers();
app.MapHealthChecks("/health");

app.Run();

Custom and Dependency Checks

Out of the box, an app with no registered checks simply reports Healthy for itself. Production systems usually need to verify external dependencies such as databases, caches, or third-party APIs. First-party packages such as Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore (registered with AddDbContextCheck<TContext>) and community packages such as AspNetCore.Diagnostics.HealthChecks cover SQL Server, Redis, and other common dependencies. For anything not covered, you implement the IHealthCheck interface and its CheckHealthAsync method, then register it with AddCheck<T>:

public class DatabaseHealthCheck : IHealthCheck
{
    public Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context,
        CancellationToken cancellationToken = default)
    {
        // Perform a real database query here
        return Task.FromResult(HealthCheckResult.Healthy("DB connection OK"));
    }
}

builder.Services.AddHealthChecks()
    .AddCheck<DatabaseHealthCheck>("database");

Integration with Monitoring

Exposing an HTTP endpoint is only useful if something consumes it. Orchestrators like Kubernetes use liveness and readiness probes against these endpoints to restart or route traffic away from unhealthy instances. You can also push results to systems like Prometheus or Azure Monitor using dedicated publishers. For sensitive environments, restrict access to health endpoints with authorization policies to prevent information disclosure.

Classic ASP.NET MVC 5 Difference

Classic ASP.NET MVC 5 on .NET Framework 4.8 has no built-in health check middleware. Developers typically created custom controller actions returning JSON status, or relied on external libraries like ELMAH for error tracking and Application Insights for telemetry.

Best Practices

• Secure Endpoints: Protect health endpoints behind authorization or internal network rules to avoid exposing system details to attackers.

• Avoid Heavy Logic: Ensure health checks execute quickly; long-running checks can time out load balancers and trigger false restarts.

• Separate Readiness from Liveness: Use one endpoint for readiness (dependencies must be up before accepting traffic) and another for liveness (the app process is alive), so a slow dependency does not cause unnecessary restarts.

• Log Failures: Configure logging for health check failures to aid debugging without overwhelming log storage with healthy pings.

Patterns Built Into the Framework

• Model-View-Controller (MVC): separates user input (controller), domain/data (model), and presentation (view). Controllers stay thin; business logic lives in services or the model.

• Front Controller: a single entry point — the routing middleware and endpoint routing — inspects each request and dispatches it to the matching controller action, instead of having many independent handlers.

• Chain of Responsibility / Decorator: the middleware pipeline (Program.cs) wraps every request in cross-cutting steps such as exception handling, static files, authentication, and routing, each deciding whether to pass the request on.

• Strategy: filters implement this — authorization, resource, action, exception, and result filters are interchangeable strategies applied at defined points in the action pipeline.

• Command: an action returns an IActionResult (for example ViewResult, RedirectToActionResult, ContentResult) that encapsulates “what to do with the response” and is executed later by the framework.

• Factory / Builder: WebApplicationBuilder, IConfigurationBuilder, and MvcOptions construct and configure the application; IControllerFactory and IModelBinderProvider create controllers and binders through pluggable factories.

Patterns for Data Access and Domain Layering

• Repository: wraps data access behind an interface (for example IProductRepository) so controllers depend on abstractions, which simplifies unit testing with mocks.

• Unit of Work: coordinates saving changes across multiple repositories; in practice Entity Framework Core’s DbContext already implements both repository and unit-of-work semantics, so an extra layer is only justified when it hides query details or supports multiple data sources.

• Adapter: wraps a third-party API, legacy service, or SDK behind your own interface so external changes don’t ripple through the codebase.

• Specification: encapsulates complex query criteria as reusable objects, useful when business rules produce many filter combinations.

Patterns for Structure and Communication

• Dependency Injection: the built-in container in Program.cs registers services with scoped, transient, or singleton lifetimes; controllers and views consume abstractions rather than concrete classes.

• Mediator / CQRS: popularized in ASP.NET Core by the third-party MediatR NuGet package, this decouples controllers from services by routing commands and queries through a single mediator, often splitting read models from write models.

• Observer: .NET events, IObservable<T>/IObserver<T>, and channels (System.Threading.Channels) let components react to domain events without direct coupling.

• Singleton: used for caches, configuration, or background services, but only when the type is genuinely stateless or thread-safe.

Pattern Overview

Best Practices and Common Pitfalls

• Prefer composition and injected abstractions over inheritance and static state; avoid the service locator anti-pattern unless there is no alternative.

• Register services with the narrowest lifetime that works — scoped for per-request state such as DbContext, transient for lightweight stateless services; mixing a singleton that depends on a scoped service causes captive dependency bugs.

• Don’t add a repository layer “because it is standard”: if it only forwards calls to DbContext, it adds ceremony without value.

• Keep controllers thin; put orchestration and rules in application/domain services so actions stay easy to test.

• Classic ASP.NET MVC 5 on .NET Framework 4.8 uses the same core patterns, but wiring happens in Global.asax, RouteConfig, and FilterConfig, and dependency injection typically requires a third-party container such as Unity or Ninject rather than the built-in provider.

Single Responsibility and Interface Segregation

• Thin controllers: an action should only coordinate the request, never contain business rules. Move validation, calculations and data access into separate service classes so each class has one reason to change.

• Focused interfaces: define one interface per capability, such as IOrderService or IEmailSender, rather than one large IService. This keeps implementations swappable and keeps unit tests isolated to a single behaviour.

Dependency Inversion and Liskov Substitution

• Depend on abstractions: inject interfaces into controllers via constructor injection; the framework resolves them from the DI container configured in Program.cs. Controllers never instantiate services directly.

• Substitutability: any implementation of an interface must be usable wherever the abstraction is expected, without changing the caller’s behaviour. Avoid throwing NotImplementedException in alternate implementations, since that breaks substitution at runtime.

Open/Closed Principle

• Extension over modification: use filters, middleware and the options pattern to add behaviour without editing controllers. For example, a custom attribute implementing IActionFilter adds logging across actions without touching them.

• Classic MVC 5 differs: it uses Global.asax, FilterConfig and manual dependency resolution rather than the built-in container.

Common Pitfalls

• Service locator: calling HttpContext.RequestServices.GetService inside actions hides dependencies and breaks testability; use constructor injection instead.

• God services: one interface with dozens of methods violates interface segregation; split it by consumer so each client depends only on what it uses.

• Concrete dependencies: injecting DbContext directly into controllers couples the web layer to EF Core; wrap it behind a repository or service interface.

• Over-engineering: applying every principle to a small prototype adds indirection without benefit; introduce abstractions when behaviour actually varies.

Core Concept and Benefits

• Definition: Every abstraction, process, or representation in a software system should occur exactly once.

• Benefit: Changes require updates in only one location, reducing the risk of inconsistencies and bugs.

• Risk: Over-engineering can occur if abstraction is applied too early to logic that isn’t actually repeated.

Areas of Application in ASP.NET Core MVC

• Filters: Handle cross-cutting concerns like logging, caching, or authorization without repeating logic in every action. For example, a custom IActionFilter that logs execution time can be registered once in Program.cs with options.Filters.Add<TimingActionFilter>() after adding the type to dependency injection, applying it globally to every action. Filters run in a specific order: authorization, resource, action, exception, and result.

• View Components: Replace classic child actions to render reusable UI sections with their own logic and lifecycle.

• Tag Helpers: Encapsulate HTML generation logic, allowing custom elements like <email-support /> to render consistent markup.

• Model Validation: Define validation rules once using data annotations on models or view models; with [ApiController], invalid models automatically return a 400 status code.

• Base Controllers: Share common action logic, though filters are generally preferred for cross-cutting concerns to keep inheritance hierarchies flat.

Filter Execution Order

Understanding the pipeline is crucial when placing shared logic. The correct execution sequence is: 1. Authorization Filters: Run first to determine if the user is allowed. 2. Resource Filters: Handle caching or setup before model binding. 3. Action Filters: Run around action execution (before/after). 4. Exception Filters: Handle unhandled exceptions. 5. Result Filters: Run around action result execution.

Best Practices and Pitfalls

• Use Filters for Cross-Cutting Concerns: Logging, security, and caching belong in filters, not inside every action method.

• Prefer View Components Over Child Actions: Classic MVC used Html.Action; ASP.NET Core uses View Components for reusable UI logic.

• Avoid Deep Inheritance: Relying heavily on base controllers can make testing difficult; composition via filters is more flexible.

• Secure Shared Forms: When reusing form templates, ensure antiforgery tokens are included; the form tag helper adds this automatically, and [ValidateAntiForgeryToken] validates it.

• Prevent Over-Posting: Use view models tailored to the view rather than binding entities directly, even when reusing binding logic.

Architecture Overview

• The ASP.NET Core app hosts both the API endpoints and the compiled SPA static assets.

• Controllers marked with [ApiController] return JSON automatically; the client framework (React, Angular, Vue, or Blazor WebAssembly) handles routing, state, and rendering.

• The React and Angular SPA project templates were removed from the .NET 8 SDK (deprecated since .NET 6); the recommended approach is to use the framework’s own tooling (Vite, Angular CLI) and let ASP.NET Core serve the built files or proxy to the dev server.

• Classic ASP.NET MVC 5 on .NET Framework 4.8 used the same split pattern but relied on Web API 2 controllers alongside MVC controllers and the Microsoft.AspNet.WebApi.Cors package.

Request Flow

1. The browser requests the root URL and receives the SPA shell (index.html plus scripts and styles).

2. The client-side router handles all subsequent navigation without contacting the server.

3. UI actions call API endpoints such as /api/products, which run model binding and validation.

4. Under [ApiController] invalid models return 400 automatically before the action runs.

Serving the SPA

• Add the Microsoft.AspNetCore.SpaServices.Extensions NuGet package for UseSpa and UseProxyToSpaDevelopmentServer.

• In development, proxy requests to the JavaScript dev server so hot reload works.

• In production, serve the pre-built static files from wwwroot using UseStaticFiles and a fallback route so client-side URLs resolve.

• Enable CORS with AddCors and UseCors only when the SPA is hosted on a different origin; same-origin deployments do not need it.

Code Example

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _service;

    public ProductsController(IProductService service)
    {
        _service = service;
    }

    [HttpGet]
    public async Task<ActionResult<IEnumerable<ProductDto>>> Get()
    {
        var items = await _service.GetAllAsync();
        return Ok(items);
    }

    [HttpPost]
    public async Task<ActionResult<ProductDto>> Create([FromBody] CreateProductDto dto)
    {
        var item = await _service.AddAsync(dto);
        return CreatedAtAction(nameof(Get), new { id = item.Id }, item);
    }
}

// Program.cs — requires Microsoft.AspNetCore.SpaServices.Extensions
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
builder.Services.AddCors(options =>
    options.AddPolicy("spa", p => p.WithOrigins("http://localhost:5173")
        .AllowAnyMethod().AllowAnyHeader()));

var app = builder.Build();

app.UseStaticFiles();
app.UseRouting();
app.UseCors("spa");
app.UseAuthorization();

app.MapControllers();
app.MapFallbackToFile("index.html");

if (app.Environment.IsDevelopment())
{
    // Proxy API and fallback requests to the JS dev server (e.g., Vite)
    app.UseSpa(spa => spa.UseProxyToSpaDevelopmentServer("http://localhost:5173"));
}

Best Practices

• DTOs over entities: accept and return view models or DTOs, never bind entity classes directly, to prevent over-posting.

• Validation: use data annotations on DTOs and rely on ModelState.IsValid; [ApiController] returns 400 for you.

• Security: protect API endpoints with [Authorize], enforce HTTPS, and use parameterized queries in the data layer.

• Versioning: version your API routes (/api/v1/products) so the client and server can evolve independently.

• Deployment: pre-build the SPA during publish so wwwroot contains the final assets and no Node.js runtime is needed on the server.

The REST Constraints

REST is not a protocol but a set of constraints; a service that ignores them is often called “REST-ish” rather than RESTful:

• Client–server: clients and servers evolve independently; the server owns the data, the client owns the UI.

• Statelessness: every request contains everything the server needs to process it; no server-side session state between requests.

• Cacheable: responses declare whether they may be cached (Cache-Control, ETag), which improves scalability.

• Uniform interface: resources are identified by URIs, manipulated through representations, messages are self-descriptive, and hypermedia links drive application state (HATEOAS).

• Layered system: intermediaries (proxies, load balancers, gateways) can sit between client and server transparently.

• Code on demand: optional — the server may ship executable code such as JavaScript to the client.

RESTful Principles for HTTP APIs

The constraints translate into practical HTTP conventions:

• URIs name resources, not actions: /api/products/42 is RESTful; /api/GetProductById?id=42 is not.

• Status codes carry meaning: 200 OK, 201 Created (with a Location header), 204 No Content, 400 Bad Request, 404 Not Found, 409 Conflict, 500 Internal Server Error.

• Content negotiation: clients and servers agree on JSON or XML through Accept and Content-Type headers.

• Statelessness and idempotency: repeated PUT or DELETE requests should leave the system in the same state, which makes retries safe.

Mapping REST onto ASP.NET Core MVC

ASP.NET Core MVC supports RESTful APIs directly; the MVC and Web API stacks have been unified since ASP.NET Core 1.0 — the same ControllerBase serves both views and JSON:

• Attribute routing with [Route("api/[controller]")] makes resource URIs explicit instead of relying on conventional routes.

• [ApiController] on an assembly or controller enables API-specific behaviors: automatic 400 responses for failed model validation, inference of [FromBody] / [FromRoute] / [FromQuery], and multipart/form-data inference for complex types. Without it, check ModelState.IsValid yourself.

• Method attributes ([HttpGet], [HttpPost], [HttpPut], [HttpPatch], [HttpDelete]) bind HTTP verbs to actions, and route templates with constraints ([HttpGet("{id:int}")]) keep URIs clean.

• ProducesResponseType and ProblemDetails document and standardize error payloads, which OpenAPI/Swagger reads to generate accurate client contracts.

• DTOs or view models instead of entity classes prevent over-posting and let you shape representations independently of the database schema.

In classic ASP.NET MVC 5 on .NET Framework 4.8, REST APIs were built with the separate ASP.NET Web API 2 stack: controllers derived from ApiController, routes were configured in WebApiConfig.cs, and there was no [ApiController] attribute behavior.

Best Practices and Common Pitfalls

• Use plural nouns and a stable versioning scheme (/api/v1/products) so clients survive breaking changes; version with route segments, query strings, or media types.

• Return the right code, not always 200: a missing resource is 404, a validation failure is 400, a duplicate is 409; wrapping errors in { "status": 200, "error": "..." } breaks HTTP semantics and client libraries.

• Never bind entity classes directly from user input: accept a DTO or view model, or use [Bind], to stop attackers setting properties you never exposed.

• Support pagination, filtering, and sorting through query strings (?page=2&pageSize=20&category=tea) rather than separate URIs, and return total counts or Link headers for navigation.

• Keep it stateless: store per-client state in tokens or the database, not in server memory, so requests can be load-balanced freely.

• Serve everything over HTTPS and consider idempotency keys for POST operations that must not be duplicated on retry.

Authentication

Authentication proves who the caller is. For stateless APIs the mainstream choice is JWT Bearer tokens, wired up with AddAuthentication and AddJwtBearer in Program.cs. The token’s issuer, audience, lifetime and signing key are validated on each request. For browser-based clients that rely on cookies, cookie authentication with antiforgery protection is appropriate instead. Signing keys, client secrets and connection strings must never be hardcoded; read them from configuration backed by User Secrets in development or Azure Key Vault in production.

Authorization

Authorization decides what an authenticated user may do. Apply the [Authorize] attribute to controllers or actions to require a signed-in user, and [AllowAnonymous] on public endpoints such as login or health checks. Fine-grained control comes from policies registered with AddAuthorization, which can require specific roles, claims, or custom requirements.

Transport and Cross-Origin Security

Always enable HTTPS redirection (and HSTS in production environments) so credentials and tokens are never sent in cleartext; this applies to Windows, Linux and container deployments alike. Configure CORS with explicit trusted origins rather than AllowAnyOrigin, and never combine AllowAnyOrigin with AllowCredentials. Antiforgery tokens are not used for token-based APIs; they only apply to cookie-authenticated browser clients, where the form tag helper emits the token and [ValidateAntiForgeryToken] validates it.

Input Validation and Rate Limiting

Treat every request body, query string and header as untrusted. Data annotations on DTOs or view models validate shape and ranges, and [ApiController] automatically returns HTTP 400 when ModelState is invalid. Bind DTOs rather than entity classes to prevent over-posting. Rate limiting, available since .NET 7, throttles abusive clients per endpoint (per-IP requires a custom partitioner).

Code Example

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidAudience = builder.Configuration["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]))
        };
    });
builder.Services.AddAuthorization(options =>
    options.AddPolicy("AdminOnly", policy => policy.RequireRole("Admin")));
builder.Services.AddCors(options =>
    options.AddPolicy("TrustedClients", policy =>
        policy.WithOrigins("https://client.example.com")
              .AllowAnyMethod().AllowAnyHeader()));
builder.Services.AddRateLimiter();

var app = builder.Build();
app.UseHttpsRedirection();
app.UseHsts(); // typically conditional on non-development in templates
app.UseCors("TrustedClients");
app.UseAuthentication();   // must come before UseAuthorization
app.UseAuthorization();
app.UseRateLimiter();
app.MapControllers();
app.Run();