ASP.NET Core MVC interview questions covering mvc fundamentals, controllers, views & routing.
Open a question for the full answer, code and interview guidance.
ASP.NET Core MVC is a web application framework built on ASP.NET Core that implements the Model-View-Controller architectural pattern. It separates an application into models that represent data and business concepts, views that render the user interface, and controllers that handle incoming requests and coordinate application behavior.
MVC stands for Model-View-Controller. The Model represents application data, domain rules, or view-specific data. The View is responsible for presenting HTML to the user. The Controller receives HTTP requests, coordinates application services or models, and selects the response, often by returning a view.
An HTTP request first enters the ASP.NET Core middleware pipeline. Routing identifies a matching endpoint, and MVC then selects the appropriate controller and action. Model binding creates action parameters from request data, validation runs, filters execute at their defined stages, and the action method produces an IActionResult or another supported result.
A controller is a class that groups related request-handling actions. MVC controllers normally inherit from Controller, which provides helpers such as View, RedirectToAction, NotFound, BadRequest, and access to ViewData, ViewBag, TempData, HttpContext, and ModelState.
An action method is a public controller method that can be selected by MVC to handle a request. It accepts bound input values, performs or coordinates the required work, and returns a response such as a view, redirect, JSON result, file, status code, or another action result.
IActionResult is an abstraction representing the result of an MVC action. Different implementations describe different HTTP responses, including ViewResult, RedirectToActionResult, NotFoundResult, FileResult, JsonResult, and ContentResult.
ControllerBase provides the core functionality needed for controller-based request handling, including HttpContext, routing data, ModelState, and response helper methods. It does not provide view-specific functionality.
A basic MVC application registers MVC services with AddControllersWithViews, configures the middleware pipeline, and maps one or more controller routes. Controllers are placed in the Controllers folder by convention, while Razor views are typically organized under Views/{ControllerName}.
AddControllersWithViews registers services required for controllers with views. It enables the MVC controller infrastructure together with view-related services needed for server-rendered applications.
A Razor view is a .cshtml file that combines HTML with Razor syntax to generate server-rendered output. Views receive data from controllers, commonly through strongly typed view models, and use Razor expressions, directives, tag helpers, partials, layouts, and sections to build the final HTML.
For a controller-specific view, MVC conventionally looks under Views/{ControllerName}/{ViewName}. It can also look under Views/Shared for views shared across controllers. For example, HomeController returning View() from its Index action normally resolves Views/Home/Index.cshtml.
A strongly typed view declares its model type with the @model directive. Razor then exposes that object through the Model property with compile-time type information and IntelliSense.
A ViewModel is a class designed specifically for the data and input needs of a view or UI workflow. It can combine values from multiple domain entities, contain display-specific properties, and expose only fields that the user is allowed to submit.
ViewData is a dictionary-based mechanism that stores values by string keys. ViewBag is a dynamic wrapper around ViewData that provides property-style syntax. Both are useful for small amounts of supplemental view data but provide less compile-time safety than a strongly typed model.
TempData stores data until it is read in a subsequent request, making it useful for short-lived messages across redirects. A common example is displaying a success notification after a POST action redirects to a GET action.
A layout is a shared Razor template that defines common page structure such as the HTML document, header, navigation, footer, styles, and scripts. Individual views render their page-specific content into the layout through RenderBody.
_ViewStart.cshtml contains Razor code that should run before views in its directory hierarchy. Its most common purpose is to specify the default Layout for multiple views without repeating the Layout assignment in every .cshtml file.
_ViewImports.cshtml centralizes Razor directives that should apply to views in a folder hierarchy. It commonly contains @using directives, @addTagHelper registrations, and @namespace settings.
Tag Helpers are server-side components that participate in generating or modifying HTML elements in Razor views. Built-in Tag Helpers support forms, labels, inputs, validation messages, links, scripts, and other common MVC tasks.
A partial view is a reusable Razor view fragment that renders part of a page rather than a complete page. It is useful for repeated presentation markup such as product cards, address blocks, or common form fragments.
A View Component is a reusable UI component that combines server-side C# logic with a Razor view. It is useful when a portion of a page needs its own data retrieval or processing, such as a shopping cart summary, navigation menu, or featured-products widget.
Routing matches incoming request URLs to application endpoints and also generates URLs for links and redirects. In MVC, a route normally identifies values such as controller, action, and route parameters.
Conventional routing defines route patterns centrally, usually in Program.cs. A common default pattern is {controller=Home}/{action=Index}/{id?}, which maps URL segments to controller and action names and makes the id segment optional.
Attribute routing defines route templates directly on controllers or actions using attributes such as Route, HttpGet, and HttpPost. It provides precise control over URLs and is useful when an endpoint does not fit a global conventional pattern.
Conventional routing defines reusable URL patterns in the application's endpoint configuration and determines controller/action values from those patterns. Attribute routing places route templates on individual controllers and actions.