Dependency Injection in ASP.NET Core Explained

Dependency Injection (DI) is a core feature of ASP.NET Core — not an add-on, but a first-class citizen of the framework. It powers how your app resolves services, handles dependencies, and stays loosely coupled.

In this article, we’ll take a deep dive into how DI works in ASP.NET Core. We’ll learn how to structure your application around DI to keep it clean, testable, and maintainable. Whether you’re using Minimal APIs or full-blown Controllers, DI is the backbone of scalable .NET applications.

We won’t cover service lifetimes here — that’s coming in the next article.

Let’s get into it.

What is Dependency Injection in ASP.NET Core?

Dependency Injection (DI) is a design pattern that helps you build software that’s easier to manage, test, and scale. At its core, DI is about giving a class what it needs, instead of letting it create those things itself.

Think of it like this: if a class needs to send an email, it shouldn’t be responsible for creating the email service — it should just say, “I need something that can send emails,” and let the system provide it. That’s what DI does.

In ASP.NET Core, this is built right into the framework. When your application starts, it sets up a Dependency Injection container, which knows how to create and manage your services. Then, whenever a class needs something — like a logging service, a database context, or a custom service you wrote — the container automatically provides it.

This leads to a few big benefits:

• Your code becomes loosely coupled, meaning one part of the system doesn’t rely too heavily on the specific details of another.
• It’s much easier to test, because you can replace real services with test versions (like mocks or fakes) without changing any production code.
• Your architecture stays clean and flexible, making it easier to swap out parts or add new features down the road.

In short, Dependency Injection helps you write better .NET applications by keeping your code focused on what it should do — not how to glue everything together.

Basic Concept

Without DI:

public class NotificationService
{
    private readonly EmailService _emailService = new();

    public void Send() => _emailService.SendEmail();
}

This is tightly coupled because NotificationService directly creates an instance of EmailService. That means:

• It’s locked to a specific implementation
• You can’t replace EmailService with a mock, fake, or alternative without modifying NotificationService itself

To unit test NotificationService, you’d ideally want to isolate it and verify behavior independently. But since it internally instantiates EmailService, you:

• Can’t intercept or verify email sending
• Can’t inject a mock or spy to test interactions
• Might accidentally send real emails during tests

To test it properly, you’d have to rewrite the class, which defeats the purpose of unit testing and violates the Open/Closed Principle.

Using DI fixes this by allowing you to inject any implementation — including test doubles — without changing the class logic.

With DI:

public class NotificationService(IEmailService emailService)
{
    public void Send() => emailService.SendEmail();
}

Now:

• NotificationService relies on an interface (IEmailService)
• The DI container injects the concrete implementation at runtime
• You can easily swap implementations or use mocks in tests

This is the foundation of how ASP.NET Core resolves services internally — whether you’re working with Minimal APIs, Controllers, or Background Services.

Dependency Injection is a fundamental part of ASP.NET Core’s architecture. Unlike older frameworks where DI was optional or required third-party containers, ASP.NET Core comes with built-in support for DI at its core. Every part of the framework — from controllers to middleware, background services to endpoint handlers — is designed to work with DI seamlessly.

When you register services in Program.cs, ASP.NET Core takes care of resolving and injecting them wherever they’re needed. Whether you’re building a Minimal API or a full MVC app, adding a dependency to a constructor or delegate automatically tells the framework to pull that service from the container. This eliminates manual wiring and reduces boilerplate, making your code more focused and maintainable.

Beyond just convenience, DI in ASP.NET Core promotes clean architecture. It enforces separation of concerns by encouraging the use of interfaces and abstractions. This makes your codebase easier to test, swap out components, and extend over time. It also improves long-term maintainability by keeping components loosely coupled and independently testable.

In short, DI isn’t just supported in ASP.NET Core — the entire framework is built around it. Ignoring it means fighting the framework and ending up with rigid, harder-to-test code. Embracing DI the right way gives you structure, flexibility, and long-term scalability.

Built-in Support for DI in ASP.NET Core

ASP.NET Core includes a built-in Dependency Injection (DI) container that is lightweight, fast, and deeply integrated into the framework. Unlike other frameworks where you might need to bring in third-party libraries just to get DI working, ASP.NET Core makes it available out of the box, no setup required.

From the moment your app starts, the DI container is in play. You configure it in the Program.cs file using the builder.Services collection. Here, you register interfaces and their concrete implementations, which the framework then resolves automatically whenever they’re needed. This applies to everything: controllers, minimal API handlers, Razor Pages, middleware, background services, and more.

What makes this powerful is that DI isn’t just available — it’s the default behavior. For example, if a controller needs a logging service, you simply request ILogger<T> in the constructor, and ASP.NET Core handles the rest. The same goes for configuration, options pattern, database contexts, and your custom services.

The container supports constructor injection, which is the recommended and most common form. It also integrates with other features like the IOptions<T> pattern, enabling you to inject strongly typed configurations with zero plumbing code. While the built-in container covers most scenarios, you can still replace it with third-party containers like Autofac if you need more advanced features — but in most real-world apps, the built-in container is more than enough.

By standardizing DI across the entire framework, ASP.NET Core helps enforce clean, consistent architecture patterns throughout your application.

Types of Dependency Injection in ASP.NET Core

In ASP.NET Core, there are three primary types of service injection mechanisms, depending on where and how you need to consume a service:

1. Constructor Injection (Most Common)

This is the default and most recommended approach. Dependencies are provided through constructor parameters, making them explicit and enforcing immutability.

Used in:

• Controllers
• Services
• Middleware
• Background services

Example:

public class ReportService(ILogger<ReportService> logger)
{
    public void Generate() => logger.LogInformation("Generating report...");
}

2. Method Injection (Minimal APIs / Endpoint Handlers)

In Minimal APIs, you can inject services directly into the route handler methods as parameters. ASP.NET Core automatically resolves them from the DI container.

Example:

app.MapGet("/reports", (IReportService reportService) =>
{
    var report = reportService.Generate();
    return Results.Ok(report);
});

3. Property Injection (Rarely Used)

This involves setting dependencies via public properties. ASP.NET Core’s built-in DI container doesn’t support it out of the box — you’d need custom setup or a third-party container. It’s discouraged in most cases due to hidden dependencies and poor testability.

Example (not recommended):

public class ReportService
{
    public ILogger<ReportService> Logger { get; set; }

    public void Generate() => Logger?.LogInformation("Report generated");
}

Constructor & Patameter Injection - Recommended

Constructor injection works seamlessly across both Controllers and Minimal APIs in ASP.NET Core, thanks to the framework’s built-in DI container. But the way you apply it differs slightly between the two.

In traditional Controllers, constructor injection is straightforward. You define dependencies as parameters in the constructor, and ASP.NET Core automatically injects them when the controller is instantiated. This encourages clean architecture by pushing service dependencies to the edges of the system and keeping controllers focused on orchestration.

For example:

public class OrdersController(IOrderService orderService) : ControllerBase
{
    [HttpGet("{id}")]
    public IActionResult GetById(int id) => Ok(orderService.GetOrder(id));
}

Using primary constructors (C# 12), this becomes even cleaner—no need for private fields or assignment boilerplate.

Minimal APIs don’t use classes or constructors, but DI still works through parameter injection directly into the endpoint handlers. ASP.NET Core inspects the parameters and injects any services it recognizes from the container.

Example:

app.MapGet("/orders/{id}", (int id, IOrderService orderService) =>
{
    var order = orderService.GetOrder(id);
    return Results.Ok(order);
});

The same rules apply: services must be registered in builder.Services, and they’re injected automatically by type. You get the same testability and separation of concerns as controllers, but with less overhead — perfect for lightweight APIs.

Registering Dependencies in Program.cs

In ASP.NET Core, all service registrations happen in Program.cs using the builder.Services collection. This is where you define how your application’s dependencies are wired up — what interfaces map to which implementations.

The most common method is AddScoped, AddTransient, or AddSingleton — depending on the lifetime you want for the service (which we’ll cover in the next article). For now, the focus is on how to register and organize your services.

Example:

builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddSingleton<INotificationService, EmailNotificationService>();
builder.Services.AddTransient<IPaymentService, StripePaymentService>();

You can also register services using lambda expressions for more control:

builder.Services.AddScoped<IInvoiceService>(sp =>
{
    var logger = sp.GetRequiredService<ILogger<InvoiceService>>();
    return new InvoiceService(logger, "INVOICE_PREFIX");
});

For Minimal APIs, this same registration pattern enables seamless injection into endpoint delegates. The DI container resolves all registered services automatically — no manual instantiation required.

It’s best practice to keep service registration organized, especially as your project grows. Split registrations into extension methods or separate static classes per feature or layer. This is a pattern you will very likely see in clean architecture / vertical slice architecture projects.

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddApplicationServices(this IServiceCollection services)
    {
        services.AddScoped<IOrderService, OrderService>();
        services.AddScoped<ICustomerService, CustomerService>();
        return services;
    }
}

And in Program.cs:

builder.Services.AddApplicationServices();

Registering dependencies in Program.cs gives you full control over how your app is wired, and it’s a central part of enforcing clean architecture boundaries in ASP.NET Core.

Injecting Framework Services vs. Application Services

ASP.NET Core’s DI container treats framework and application services the same — once registered, they’re resolved and injected using the same mechanism. The difference lies in who registers them and what they’re used for.

Framework Services

These are built-in services that ASP.NET Core registers automatically. You don’t need to add them manually — they’re ready to inject anywhere in your app.

Examples include:

• ILogger<T> for structured logging
• IConfiguration for accessing app settings
• IWebHostEnvironment for environment-specific behavior
• IHttpContextAccessor for accessing the current HTTP context
• IOptions<T> for binding configuration to typed objects

These can be injected directly into constructors or minimal API handlers:

public class AuditService(ILogger<AuditService> logger, IConfiguration config)
{
    public void Log() => logger.LogInformation($"Env: {config["ASPNETCORE_ENVIRONMENT"]}");
}

Application Services

Application services are the interfaces and implementations you define for your business logic — such as IUserService, IPaymentProcessor, or INotificationService.

These services must be registered explicitly in Program.cs:

builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddSingleton<IEmailService, EmailService>();

Once registered, they can be injected just like framework services:

public class UserController(IUserService userService)
{
    [HttpGet("{id}")]
    public IActionResult GetUser(int id) => Ok(userService.GetById(id));
}

Both types of services benefit from the same DI pipeline, making it easy to compose functionality, enforce separation of concerns, and keep your codebase clean and testable.

Interface-Driven Design with DI

Dependency Injection works best when combined with interface-driven design — a practice where components depend on abstractions (interfaces) rather than concrete implementations.

Instead of tightly coupling your services to specific classes, you define behavior through interfaces and inject those interfaces wherever needed. This keeps components loosely coupled and makes your code easier to test, extend, and replace.

For example, instead of this:

public class ReportService(EmailService emailService)
{
    public void Generate() => emailService.Send();
}

Use this:

public interface IEmailService
{
    void Send();
}

public class EmailService : IEmailService
{
    public void Send() => Console.WriteLine("Sending Email");
}

public class ReportService(IEmailService emailService)
{
    public void Generate() => emailService.Send();
}

Now ReportService only knows about the contract (IEmailService), not the actual implementation. You can register the mapping once in Program.cs:

builder.Services.AddScoped<IEmailService, EmailService>();

And during testing, you can easily substitute a mock:

var mockEmailService = Substitute.For<IEmailService>();
var reportService = new ReportService(mockEmailService);

This approach reinforces the Dependency Inversion Principle — one of the SOLID principles — by making high-level modules independent of low-level implementations. With DI and interfaces together, your code becomes more modular, testable, and open to change without breaking existing behavior.

Inversion of Dependency and How It Helps in Clean Architecture

The Inversion of Dependency Principle is fundamental to Clean Architecture. It flips the typical dependency direction: instead of your core logic depending on concrete implementations (like SMTP clients, file systems, or databases), those external details depend on the core through interfaces. This keeps your core logic clean, stable, and testable — and allows your infrastructure to change without breaking everything.

Let’s look at a real-world example using an email service.

Without Inversion (Tightly Coupled)

Here’s a NotificationService directly using an SMTP implementation:

public class NotificationService
{
    private readonly SmtpEmailService _emailService = new();

    public void SendWelcomeEmail(string to)
    {
        _emailService.Send(to, "Welcome!", "Thanks for signing up!");
    }
}

This tightly couples the class to one implementation. You can’t test it easily without sending real emails, and switching to another provider (like SendGrid) requires editing this class.

With Inversion of Dependency

Step 1: Define an abstraction in your Core layer:

public interface IEmailService
{
    void Send(string to, string subject, string body);
}

Step 2: Update NotificationService to depend on the interface:

public class NotificationService(IEmailService emailService)
{
    public void SendWelcomeEmail(string to)
    {
        emailService.Send(to, "Welcome!", "Thanks for signing up!");
    }
}

Now this class has no idea how emails are sent. It’s focused only on business logic.

Step 3: Create concrete implementations in the Infrastructure layer

SMTP implementation:

public class SmtpEmailService : IEmailService
{
    public void Send(string to, string subject, string body)
    {
        // SMTP logic here
        Console.WriteLine($"[SMTP] Sent email to {to}: {subject}");
    }
}

SendGrid implementation:

public class SendGridEmailService : IEmailService
{
    public void Send(string to, string subject, string body)
    {
        // SendGrid logic here
        Console.WriteLine($"[SendGrid] Sent email to {to}: {subject}");
    }
}

Step 4: Register the implementation in Program.cs

// Use SMTP
builder.Services.AddScoped<IEmailService, SmtpEmailService>();

// OR, switch to SendGrid with one line
// builder.Services.AddScoped<IEmailService, SendGridEmailService>();

That’s it — no changes required in your core logic. Just swap the implementation at the edge, and everything works.

This is the essence of Inversion of Dependency. Your core application defines what needs to happen, and your infrastructure decides how it happens. The result is a clean, decoupled architecture that’s easy to test, extend, and maintain.

In our course, we will also build a full fleged Clean Architecture and Vertical Slice Architecture solutions. Stay Tuned!

Common Dependency Injection Mistakes to Avoid

While Dependency Injection is a powerful pattern, it’s easy to misuse — especially in larger ASP.NET Core applications. Here are some common pitfalls to watch out for:

1. Service Locator Anti-Pattern

Avoid manually resolving services using IServiceProvider inside your classes:

public class BadService(IServiceProvider provider)
{
    public void DoWork()
    {
        var repo = provider.GetService<IRepository>();
        // ...
    }
}

This hides dependencies, makes the class harder to test, and breaks the whole point of DI. Always prefer constructor injection to make dependencies explicit.

2. Too Many Dependencies in One Class

If a class has 5–10 constructor parameters, that’s a red flag. It usually means the class is doing too much and needs to be split into smaller, focused components.

Example:

public class OrderController(
    IOrderService orderService,
    ICustomerService customerService,
    IInventoryService inventoryService,
    IShippingService shippingService,
    INotificationService notificationService
)

3. Not Registering Services Correctly

Forgetting to register a service in Program.cs leads to runtime errors:

InvalidOperationException: Unable to resolve service for type 'IEmailService'

Make sure every injected interface has a matching registration:

builder.Services.AddScoped<IEmailService, EmailService>();

4. Mixing Service Lifetimes Improperly

Injecting a scoped service into a singleton will cause runtime errors or unexpected behavior. This happens when lifetimes are mismatched. (Covered in detail in the next article.)

5. Overusing Interfaces for Everything

Interfaces are essential for abstractions, but don’t abstract everything. For example, you don’t need an interface for a static helper or a data model with no behavior. Use interfaces where it provides real benefits — like testability, flexibility, or separation of concerns.

6. Injecting Configuration Values Directly

Instead of injecting IConfiguration everywhere, bind configuration to strongly typed objects using the IOptions<T> pattern:

builder.Services.Configure<EmailSettings>(config.GetSection("EmailSettings"));

And inject:

public class EmailService(IOptions<EmailSettings> options) { }

This keeps your code clean and config-aware without hardcoding strings.

I have an entire article covering IOptions Pattern in ASP.NET Core. Do read it to get a clearer understanding.

Avoiding these pitfalls will help you get the most out of DI in ASP.NET Core — keeping your codebase maintainable, testable, and scalable as your app grows.

Advanced Scenarios: Conditional Registrations & Factory Delegates

For most cases, registering services in Program.cs using AddScoped, AddSingleton, or AddTransient is enough. But sometimes you need more control — especially when the service needs to be configured dynamically, or the implementation depends on runtime logic. That’s where conditional registrations and factory delegates come in.

Conditional Registrations

ASP.NET Core’s built-in DI container doesn’t support out-of-the-box conditional resolution (like “inject this implementation only if condition X is met”). But you can work around it using factories or decorators.

PS, there is a new feature called Keyed Services, which I will be covering in one of the next articles. But I believe that it’s important for you know the factory pattern approach to get a better understanding. Once you are clear with this, learning about Keyed Services would make even more sense.

Example: register two implementations of the same interface and resolve based on a condition.

public interface IPaymentService { void Process(); }
public class StripePaymentService : IPaymentService { /*...*/ }
public class RazorpayPaymentService : IPaymentService { /*...*/ }

builder.Services.AddScoped<StripePaymentService>();
builder.Services.AddScoped<RazorpayPaymentService>();
builder.Services.AddScoped<IPaymentService>(provider =>
{
    var config = provider.GetRequiredService<IConfiguration>();
    var useStripe = config.GetValue<bool>("UseStripe");

    return useStripe
        ? provider.GetRequiredService<StripePaymentService>()
        : provider.GetRequiredService<RazorpayPaymentService>();
});

This lets you inject IPaymentService as usual, but the actual implementation is chosen at runtime based on config.

Factory Delegates

Sometimes, you need to create a service based on runtime parameters that DI alone can’t provide. Factory delegates let you register a function that can create an instance on demand.

Example:

public delegate IEmailService EmailServiceFactory(string region);

Register:

builder.Services.AddScoped<EmailService>();
builder.Services.AddScoped<EmailServiceFactory>(sp => region =>
{
    var config = sp.GetRequiredService<IConfiguration>();
    var settings = config.GetSection($"Email:{region}").Get<EmailSettings>();

    return new EmailService(settings);
});

Use:

public class NotificationSender(EmailServiceFactory emailFactory)
{
    public void Send(string region)
    {
        var service = emailFactory(region);
        service.SendEmail();
    }
}

This pattern is powerful when services need to vary based on request data, multi-tenancy, or dynamic behavior not known at app startup.

By using factory delegates and conditional logic during service registration, you can keep your application flexible without polluting business logic with setup concerns.

DI vs. Service Locator: Don’t Mix Them Up

Dependency Injection (DI) and the Service Locator pattern might seem similar on the surface — both resolve dependencies — but they represent opposite philosophies when it comes to architecture and testability.

Dependency Injection

With DI, dependencies are explicitly declared via constructors (or method parameters in Minimal APIs). The DI container is responsible for resolving and injecting them when the class is created. This promotes:

• Loose coupling
• Clear contracts
• Easy unit testing
• Strong compile-time safety

Example:

public class ReportService(IEmailService emailService)
{
    public void Generate() => emailService.Send();
}

Everything this class needs is clear from the constructor.

Service Locator

With the Service Locator pattern, the class requests dependencies at runtime, usually via IServiceProvider. This hides the class’s real dependencies and introduces tight coupling to the DI container itself.

Example:

public class ReportService(IServiceProvider provider)
{
    public void Generate()
    {
        var emailService = provider.GetService<IEmailService>();
        emailService.Send();
    }
}

Why this is a problem:

• Hidden dependencies (nothing in the constructor tells you what’s required)
• Harder to test (you must mock IServiceProvider)
• Violates the Dependency Inversion Principle
• Encourages tightly coupled, procedural code

Bottom Line

DI is about declaring what you need.
Service Locator is about asking for it behind the scenes.

Stick to constructor injection or method injection via ASP.NET Core’s DI container. Avoid injecting IServiceProvider unless you’re in advanced scenarios like plugin systems or dynamic resolution — and even then, isolate it behind a factory or wrapper.

When Not to Use DI (Yes, Sometimes It Happens)

While Dependency Injection is a powerful and often essential tool in ASP.NET Core applications, there are scenarios where not using DI is the better choice. Knowing when to skip it helps you avoid unnecessary complexity and keep your code clean.

1. Pure Utility or Static Helpers

If a class has no state and no dependencies — like DateTimeProvider.UtcNow(), a string manipulator, or a simple math utility — injecting it adds no real value. Use static methods instead of wiring them through DI just for the sake of consistency.

Example:

public static class SlugGenerator
{
    public static string Generate(string input) => /* logic */;
}

2. Simple Composition Root Logic

Startup or host configuration code — like building the application, reading configuration files, or seeding a database — doesn’t always need to be injected. DI is best used for runtime dependencies, not one-time startup logic.

var configuration = builder.Configuration;
var environment = builder.Environment;

These are already available without injecting anything.

3. Factory-Style Object Creation

If an object requires dynamic input at runtime (like user input or request data), and doesn’t fit into the standard DI graph, it’s often better to create it manually or through a factory. Don’t force it into DI if it doesn’t belong.

var report = new Report(userId, DateTime.UtcNow); // Don't inject this

4. Over-Abstracting for Small Projects

In small apps or prototypes, you might not need interfaces for every service. Overusing DI early can lead to unnecessary indirection and boilerplate. Start simple. Add abstractions when they solve real problems — like testability or swapping implementations.

5. Inside Tight Loops or Performance-Critical Paths

Avoid resolving services from the container inside loops or per-request logic unless absolutely necessary. Doing so can create overhead or unintended lifetimes. Instead, resolve the service once and reuse it.

In short, DI is a tool — not a rule. Use it where it adds clarity, testability, or scalability. Skip it when it adds friction without value.

Wrap-Up: How DI Keeps Your Codebase Clean and Scalable

Dependency Injection is more than just a way to wire up services — it’s a foundational design principle that helps you build modular, testable, and maintainable applications.

By injecting dependencies instead of instantiating them, you reduce coupling and promote clear separation of concerns. Your classes focus only on what they need to do, not how to create the things they depend on. Combined with interfaces, DI enforces contracts and enables effortless unit testing.

ASP.NET Core’s built-in container makes this seamless — from controllers to minimal APIs to background services. And with the flexibility to use factories, conditional logic, or override services during testing, you can handle even complex scenarios without sacrificing clarity.

If you’re building serious applications in .NET, learning to use DI properly isn’t optional — it’s how you keep your codebase clean as it grows, onboard new devs faster, and scale features without introducing a mess.

This article is Chapter 1 of our FREE .NET Web API Zero to Hero Series → Start the course here

Next up:

• ✅ Service Lifetimes (Scoped, Singleton, Transient)
• ✅ Keyed Services in .NET 8+

If you found this helpful, share it with your dev circle — and if there’s a specific DI-related topic or .NET concept you’d like to see covered next, drop a comment and let me know.