The first time I see a class creating five or six services with new, I know maintaining that code will become harder than necessary. Dependency injection in ASP.NET Core explained simply means letting the framework supply the objects a class needs instead of forcing that class to create them itself.
ASP.NET Core includes a dependency injection container by default. I do not need a third-party library for normal DI scenarios. Once services are registered, the framework can create them, manage their lifetimes, and inject them where needed.
That sounds simple. The part developers usually need to understand is how registration, resolution, and service lifetimes work together.
What Dependency Injection Actually Does
Suppose a controller needs an email service.
Without DI, the controller might contain this:
var emailService = new EmailService();
Now the controller knows exactly which implementation it uses. Replacing EmailService, mocking it during testing, or changing its dependencies becomes harder.
With dependency injection, I depend on an abstraction instead:
public HomeController(IMessageService messageService)
{
_messageService = messageService;
}
ASP.NET Core determines which implementation should satisfy IMessageService based on registrations configured when the application starts.
Microsoft describes dependency injection as a technique for achieving Inversion of Control between classes and their dependencies. The official ASP.NET Core dependency injection documentation covers the built-in container in detail.
The result is lower coupling. Classes focus on their own responsibilities rather than constructing the entire object graph beneath them.
How the ASP.NET Core DI Container Works
I find DI much easier to reason about when I separate it into three pieces.
A dependency is something another class needs. An email service, repository, logger, or database context can all be dependencies.
The container is the service provider that knows which services are available and how they should be created.
Injection is the process of supplying one of those registered services to the class that requests it.
Registration normally happens through builder.Services in Program.cs.
For example:
builder.Services.AddScoped<IMessageService, EmailService>();
This tells the container that requests for IMessageService should receive an EmailService.
The AddScoped part matters just as much as the interface and implementation. It controls the lifetime of that object.
Understanding Transient, Scoped, and Singleton Lifetimes
Service lifetimes are where Dependency injection in ASP.NET Core explained becomes more practical than theoretical.
ASP.NET Core provides three common lifetime choices.
| Lifetime | Instance behavior | Typical use |
| Transient | Created each time requested | Lightweight stateless services |
| Scoped | Created once per request scope | DbContext, repositories, request-level services |
| Singleton | One instance for the application’s lifetime | Shared thread-safe services, caches |
Here is the mental model I use.
Imagine three users send three separate HTTP requests. During every request, the application needs the same service twice.
A Transient registration can produce six objects because each resolution may create another instance.
A Scoped registration normally produces three objects because each HTTP request receives one shared instance.
A Singleton registration produces one object shared across all three requests.
That simple request-by-request comparison makes lifetime selection much easier.
Transient Services
Register a transient service with:
builder.Services.AddTransient<IMessageService, EmailService>();
I use Transient when the service is lightweight, stateless, and safe to recreate frequently.
The main cost is object creation. If a transient service has an expensive dependency graph, creating it repeatedly can become unnecessary overhead.
Scoped Services
Register a scoped service with:
builder.Services.AddScoped<IMessageService, EmailService>();
In a typical ASP.NET Core web application, a Scoped service lives for one request.
Entity Framework Core DbContext is a classic example because related operations within one request can share the same context.
Scoped services also help keep request-specific state isolated between users.
Singleton Services
A Singleton is registered with:
builder.Services.AddSingleton<IMessageService, EmailService>();
The same instance can then serve requests throughout the application lifetime.
That makes Singleton useful for services designed to hold shared application-level state. However, the implementation must be safe when many requests use it concurrently.
How to Implement Dependency Injection in ASP.NET Core
The cleanest implementation follows four small steps.
Step 1: Define an Interface
Start with the contract:
public interface IMessageService
{
string SendMessage(string message);
}
The consuming class now depends on behavior rather than a concrete implementation.
Step 2: Create the Implementation
Next, implement that contract:
public class EmailService : IMessageService
{
public string SendMessage(string message)
{
return $”Email sent: {message}”;
}
}
I can later replace EmailService without rewriting every controller using IMessageService.
Step 3: Register the Service
Add the registration in Program.cs:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped<IMessageService, EmailService>();
var app = builder.Build();
Registration connects the abstraction, implementation, and lifetime.
Step 4: Inject the Dependency
Now the controller requests the abstraction:
public class HomeController : Controller
{
private readonly IMessageService _messageService;
public HomeController(IMessageService messageService)
{
_messageService = messageService;
}
public IActionResult Index()
{
var result = _messageService.SendMessage(“Hello!”);
return View((object)result);
}
}
The controller never constructs EmailService. ASP.NET Core resolves it automatically.
The same pattern becomes especially useful when learning how to build a REST API in ASP.NET Core, because controllers, repositories, database contexts, validation services, and business logic often depend on DI.
Constructor Injection and Other DI Options
Constructor injection is my default choice because dependencies remain explicit. Anyone reading the constructor can immediately see what the class requires.
ASP.NET Core also supports dependency injection directly into Minimal API handlers:
app.MapGet(“/send”, (IMessageService messageService) =>
{
return Results.Ok(messageService.SendMessage(“Hello”));
});
MVC controllers can use [FromServices] when a dependency is required by only one action rather than the entire controller.
public IActionResult Send(
[FromServices] IMessageService messageService)
{
return Ok(messageService.SendMessage(“Hello”));
}
I reserve action injection for narrow cases. If several actions require the same dependency, constructor injection usually produces cleaner code.
Microsoft documents controller-specific options in its dependency injection into controllers documentation.
Dependency Injection Mistakes I Avoid
The most dangerous lifetime mistake is allowing a long-lived Singleton to capture a shorter-lived Scoped service.
For example:
Singleton Service
↓
Scoped Repository
↓
DbContext
The Singleton may keep using an object that was designed to exist only within a request scope. This pattern is often called a captive dependency.
Rather than thinking “Singleton is faster,” I choose lifetimes based on ownership and state.
I also avoid injecting large numbers of unrelated services into one constructor. A controller needing eight or ten dependencies often signals that the class has too many responsibilities.
Another mistake is creating registered services manually with new. Doing that bypasses the container and can defeat lifetime management.
When Dependency Injection Becomes Especially Useful
Small projects may make DI feel like additional structure. Its value grows rapidly as applications expand.
Testing becomes easier because I can replace a real implementation with a fake or mock implementation. Business logic becomes less tied to databases, APIs, email providers, or storage systems.
Configuration also becomes cleaner. I can replace one implementation centrally rather than editing every class that creates it.
Most importantly, dependencies become visible. A constructor effectively documents what a class needs before it can work.
That visibility is one reason I consider dependency injection an architectural tool rather than just an ASP.NET Core feature.
FAQs
1. What is dependency injection in ASP.NET Core?
Dependency injection lets ASP.NET Core create registered services and supply them to classes that depend on them.
2. What are the three dependency injection lifetimes in ASP.NET Core?
The three standard lifetimes are Transient, Scoped, and Singleton, which control how long service instances remain available.
3. Why is constructor injection recommended in ASP.NET Core?
Constructor injection makes required dependencies explicit, supports testing, reduces coupling, and prevents classes from constructing their own dependencies.
4. Can a Singleton depend on a Scoped service?
Directly capturing a Scoped service inside a Singleton creates a lifetime mismatch and should generally be avoided.
Stop Creating Everything With new
Once Dependency injection in ASP.NET Core explained clicked for me, the feature stopped feeling like framework magic. It became a predictable system: register a service, choose the right lifetime, request the abstraction, and let the container resolve the implementation.
The lifetime decision deserves the most attention. Transient means new instances, Scoped normally means one instance per web request, and Singleton means one shared instance.
My next step on any project is simple: inspect classes that manually construct repositories, clients, or business services. Those are often the best candidates for DI. Keep dependencies explicit, keep lifetimes compatible, and the application becomes much easier to change without creating a chain reaction across the codebase.
