ASP.NET Core interview questions covering dependency injection & services.
Open a question for the full answer, code and interview guidance.
Dependency injection (DI) is a design technique in which a class receives the objects it depends on instead of creating those objects itself. ASP.NET Core includes a built-in dependency injection container.
Dependency injection separates a class from the concrete construction of its dependencies. Instead of a controller creating repositories, loggers, or services with new, those dependencies are supplied by the container.
IServiceCollection is the collection used to register services with ASP.NET Core's dependency injection container before the application is built.
IServiceProvider is the runtime service resolver built from the registrations in IServiceCollection. ASP.NET Core uses it internally to create objects and satisfy their registered dependencies.
ASP.NET Core supports three primary DI lifetimes.
Use a Transient lifetime when a service is lightweight, stateless, inexpensive to construct, and should not retain state between resolutions.
A Scoped service is appropriate when one instance should be shared within a single request or logical operation but not across unrelated requests.
A Singleton service is created once and reused for the lifetime of the application process. It is appropriate for services that are expensive to construct, hold application-wide immutable state, or safely manage shared state.
A captive dependency occurs when a longer-lived service holds a dependency with a shorter lifetime, most commonly when a Singleton directly depends on a Scoped service.
Constructor injection supplies dependencies through a class constructor. It is the most common DI technique in ASP.NET Core and is generally preferred for required dependencies.
Method injection supplies a dependency directly to a method rather than storing it on the class. In MVC controllers, an action parameter can request a registered service with the FromServices attribute.
Keyed dependency injection allows multiple implementations of the same service type to be registered and selected by a key. This is useful when an application has several strategies that implement one interface.
The common registration form maps an abstraction to a concrete implementation using AddTransient, AddScoped, or AddSingleton.
ASP.NET Core can register a concrete class directly. This is useful when there is only one meaningful implementation and an interface would not provide a useful abstraction.
A factory delegate allows custom logic to run when the DI container creates a service. The delegate receives an IServiceProvider, so it can resolve other registered services and configuration needed to construct the object.
Multiple implementations can be registered for the same service interface. When a consumer requests IEnumerable<TService>, the container supplies all registered implementations in registration order.
TryAdd extension methods register a service only when that service type has not already been registered. They are provided by Microsoft.Extensions.DependencyInjection.Extensions.
Replace removes the existing registration for a service type and adds a new ServiceDescriptor. It is useful when an application needs to replace a default registration supplied by a framework component or reusable library.
IServiceScope represents a dependency injection scope. Services registered as Scoped are shared within that scope and disposed when the scope is disposed.
IServiceScopeFactory creates IServiceScope instances. It is especially useful in singleton services and background workers that need to resolve scoped dependencies for individual operations.
The built-in DI container tracks disposable services that it creates and disposes them when the owning scope is disposed.
The Service Locator pattern occurs when application classes depend on IServiceProvider and manually request their real dependencies at runtime.
DI makes dependencies replaceable. A class can be tested with a fake, stub, or mock implementation instead of connecting to a real database, external API, file system, or email provider.
Extension methods can group related IServiceCollection registrations and keep Program.cs readable as an application grows.
Use constructor injection for required dependencies, choose lifetimes deliberately, and keep singleton services thread-safe. Avoid injecting scoped services into singletons and avoid using IServiceProvider as a general-purpose service locator.