ASP.NET Core MVC interview questions covering dependency injection, services, error handling, logging & performance.
Open a question for the full answer, code and interview guidance.
ASP.NET Core has a built-in dependency injection container. A controller normally declares its required services as constructor parameters, and the framework resolves those services when it creates the controller.
Transient services are created each time they are requested. Scoped services are created once per dependency-injection scope; in a typical MVC HTTP request, that means one instance per request. Singleton services use one instance for the application's service-provider lifetime.
Entity Framework Core DbContext represents a unit of work and is not thread-safe. In a typical web application, a scoped lifetime allows services participating in one HTTP request to share the same request-level context while keeping contexts separate across requests.
Constructor injection supplies dependencies when the controller is created and is appropriate for services used by several actions. Action injection supplies a service only to a particular action, commonly through FromServices or service-binding support.
A thin controller focuses on HTTP orchestration: receiving input, checking request-level validity, calling application services, and choosing an appropriate response. Business rules, complex workflows, and data-access logic should generally live in dedicated layers or services.
A service layer provides application operations that coordinate business rules, persistence, and other dependencies outside controllers. For example, ProductService might implement create, update, search, or pricing workflows while the controller handles HTTP concerns.
ASP.NET Core configuration can be accessed directly through IConfiguration, but strongly typed options are usually clearer for related settings. The options pattern binds configuration sections to classes and supports validation and different consumption models.
IOptions provides a straightforward singleton-style access to configured option values. IOptionsSnapshot is scoped and can provide updated values per request for supported configuration providers. IOptionsMonitor is singleton-friendly and supports retrieving current values and change notifications.
Use ILogger<T> through dependency injection. Structured logging should use message templates with named properties rather than building log messages through string concatenation.
The standard levels are Trace, Debug, Information, Warning, Error, and Critical. Trace and Debug are highly detailed; Information records normal significant operations; Warning represents unexpected or potentially problematic conditions; Error represents failures; and Critical represents severe failures requiring immediate attention.
Structured logging records named values as properties rather than flattening everything into an already-formatted string. Logging providers and observability systems can then search, filter, aggregate, and correlate events using those properties.
Unexpected exceptions are normally handled centrally rather than with repetitive try/catch blocks in every action. ASP.NET Core can use exception-handling middleware to catch failures that reach it and execute an error-handling path.
An error ViewModel supplies safe information needed by a user-facing error page, commonly a request or correlation identifier. It should not expose the raw exception or sensitive internal details to the browser.
Exception handling deals with failures represented by thrown exceptions. Status-code handling deals with completed responses such as 404 or 403 that may not involve an exception at all.
A controller can return NotFound when a requested resource does not exist. The application may also configure status-code pages so unmatched routes and other 404 responses display a consistent user-facing page.
Response caching uses HTTP caching semantics to influence whether clients or intermediary caches can reuse a response. The ResponseCache attribute can set cache-related response headers for controller actions.
Output caching is server-side middleware that can store and reuse generated responses according to configured policies. It provides application-controlled caching behavior and can reduce repeated work for suitable endpoints.
IMemoryCache stores data in the memory of the current application process. It is useful for relatively small, frequently reused data that can be recreated and does not need to be shared across multiple server instances.
A distributed cache stores cached data in an external system shared by multiple application instances. It is useful in load-balanced deployments when instances need access to common cached values or distributed session data.
Database calls, HTTP requests, file operations, and other I/O spend time waiting for external work. Using asynchronous APIs allows the request thread to return to the thread pool while the operation is waiting, which can improve throughput under concurrent load.
The N+1 problem occurs when an application executes one query to load a collection and then performs additional queries for individual items or related data. A page containing many rows can therefore trigger a large number of database round trips.
Projecting directly into a list or page ViewModel can reduce the amount of data retrieved and avoid materializing complete entity graphs that the UI does not need. With EF Core, a Select projection can often be translated into a focused SQL query.
Large result sets should be paginated at the data source rather than loading every record and then displaying only one page. A query commonly applies a deterministic OrderBy followed by Skip and Take, or uses keyset pagination for suitable high-scale scenarios.
Measure before optimizing. Use structured logs, request timing, application performance monitoring, distributed tracing where appropriate, database query diagnostics, browser network tools, and profiling to identify actual bottlenecks.
Use dependency injection with appropriate lifetimes, keep controllers thin, and put meaningful application workflows in services. Consume configuration through clear options, log structured operational information without secrets, and handle unexpected failures centrally with safe production error pages.