ASP.NET Core MVC interview questions covering controllers, actions, model binding & action results.
Open a question for the full answer, code and interview guidance.
Action selectors help MVC determine which action method can handle a request. HTTP method attributes such as HttpGet, HttpPost, HttpPut, and HttpDelete constrain an action to particular request methods, while routing attributes can further constrain the URL.
HttpGet restricts an action to HTTP GET requests. GET actions are normally used to retrieve or display information and should not perform state-changing operations.
HttpPost restricts an action to HTTP POST requests. POST actions commonly process form submissions that create or change server-side state.
Post/Redirect/Get (PRG) is a pattern where a successful POST request returns a redirect instead of directly rendering the final page. The browser then performs a GET request for the redirected URL.
NonAction tells MVC that a public method on a controller must not be treated as an action. It can be useful for public helper methods, although private or protected helper methods are often preferable when possible.
ActionNameAttribute gives an action a different externally visible action name from its C# method name. This can be useful when two methods need distinct C# names but should participate in routing under a desired action name.
Model binding converts incoming request data into action parameters and model objects. It can obtain values from route data, query strings, form fields, and other supported value providers.
MVC can bind values from several request sources, including form fields, route values, query-string parameters, uploaded files, and services when explicitly requested. In controller applications, attributes such as FromRoute, FromQuery, FromForm, and FromServices can make the intended source explicit.
FromRoute tells MVC to obtain a value from route data, FromQuery obtains it from the query string, and FromForm obtains it from submitted form fields. These attributes make the source explicit and can remove ambiguity.
For a complex object, model binding creates the object and attempts to populate its bindable properties from matching request keys. Nested property names and indexed collection names can also be bound when the submitted field names follow the expected format.
Overposting occurs when model binding allows a client to set properties that the UI was not intended to modify. This is particularly dangerous when persistence entities contain fields such as IsAdmin, Approved, OwnerId, PriceOverride, or internal status values.
ModelState contains the results of model binding and model validation for the current request. It stores attempted values and validation errors associated with fields.
After model binding, MVC validates the bound model using configured validation mechanisms. Data annotation attributes such as Required, StringLength, Range, and Compare are commonly used on input models.
Server-side validation executes on the server and must be treated as the authoritative validation layer. Client-side validation runs in the browser and improves usability by displaying errors without a full request when supported.
A controller can add an error manually with ModelState.AddModelError. This is useful for validation that depends on application logic or multiple fields, such as checking whether a username is already registered.
ViewResult is an IActionResult that renders a Razor view. Controller.View() creates a ViewResult and can optionally specify a view name and model.
RedirectToActionResult instructs the browser to make a new request to an MVC action. It is commonly created with RedirectToAction and is heavily used with the Post/Redirect/Get pattern.
Redirect sends the client to a specified URL. RedirectToAction generates a URL for an MVC controller/action, while RedirectToRoute generates a URL using a named route or route values.
ContentResult returns text content with an optional content type and status code. JsonResult serializes an object as JSON.
Controller helper methods can create HTTP status-code results. NotFound returns 404, BadRequest returns 400, Unauthorized returns 401, and StatusCode can produce a specified status code.
Controller.File provides overloads for returning file bytes, streams, or physical/virtual files with an appropriate content type and optional download filename. File responses are useful for generated reports, documents, images, and exports.
An MVC action can be asynchronous and return Task<IActionResult> or another task-based result. Async actions are especially useful for database, HTTP, file, and other I/O operations because the request thread does not need to block while waiting for the I/O to complete.
ASP.NET Core exposes a cancellation token that is signaled when the HTTP request is aborted. Passing it to asynchronous database, HTTP, and application-service operations allows unnecessary work to stop when supported.
Controllers should generally not contain repetitive try/catch blocks for every unexpected exception. Centralized exception-handling middleware or an exception handler can log unexpected failures and return an appropriate error response or page.
Keep controllers focused on HTTP and application-flow concerns: accept input, validate it, call application services, and choose the response. Use dedicated ViewModels or input models rather than binding database entities directly, and use dependency injection instead of constructing infrastructure dependencies inside actions.