Dependency Inversion Principle

A phone with a 3.5mm jackThe 3.5mm audio jack is a universal interface — any headphones with a 3.5mm plug work with any device that has a 3.5mm port. The phone doesn't know if you're using $5 earbuds or $500 studio monitors. The headphones don't know if they're plugged into a phone, laptop, or synthesizer. Both sides depend on the 3.5mm standard. doesn't care if you plug in $5 earbuds or $500 studio monitors. The phone depends on the "audio output" abstraction, not on a specific headphone model. If Apple had soldered AirPods directly into the iPhone (no jack, no Bluetooth), you'd be "welded" to one vendor — that's a DIP violation.

When you mail a letter, you don't drive it to the recipient's house. You depend on an abstraction: the postal address. The postal service (low-level) handles delivery — whether by truck, plane, or drone. You (high-level sender) and the recipient both depend on the addressing standard. Changing the delivery mechanism (USPS → FedEx → drone) doesn't change how you write the address. That's DIP: the business logic (sending a letter) doesn't know the infrastructure (delivery truck).

A CEO (high-level policy maker) doesn't write SQL queries to get sales data. They depend on a report format (abstraction) — a dashboard, a PDF, a spreadsheet. The data team (low-level) implements the report from whatever database they use. If the company migrates from Oracle to PostgreSQL, the CEO's report format doesn't change. The CEO depends on "I need sales numbers," not on "I need Oracle SQL." The dependency is invertedWithout DIP: CEO → Oracle Database (CEO depends on the implementation). With DIP: CEO → ISalesReport ← OracleSalesReport (both depend on the abstraction). The direction of the dependency has been "inverted" — it now points toward the abstraction instead of the implementation.: the implementation conforms to the abstraction, not the other way around.

Fowler published "Inversion of Control Containers and the Dependency Injection patternFowler's 2004 article (martinfowler.com) distinguished three forms of DI: constructor injection, setter injection, and interface injection. He also clarified the difference between IoC (a general principle) and DI (a specific pattern). This article established the terminology the industry uses today." in 2004, coining the term "Dependency Injection" to distinguish it from the broader "Inversion of Control." He described three injection styles: constructor injection (preferred), setter injection, and interface injection. This article became the definitive reference for DI patterns and directly influenced how .NET frameworks would later implement DI.

The .NET ecosystem exploded with IoC containers: Castle WindsorOne of the oldest .NET IoC containers (2004). Known for its powerful facilities system, interceptors, and convention-based registration. Used heavily in enterprise .NET before ASP.NET Core's built-in container. (2004), StructureMapA .NET IoC container by Jeremy Miller (2004). Pioneered auto-registration by convention (scan assemblies for types matching naming patterns). Influenced ASP.NET Core's DI design but was retired in 2018. (2004), AutofacA popular .NET IoC container (2007) that introduced module-based registration, lifetime scopes, and powerful decoration support. Still widely used alongside ASP.NET Core's built-in container for advanced scenarios. (2007), NinjectA "lightning-fast" .NET IoC container (2008) known for its fluent binding syntax and contextual binding. Popular in the ASP.NET MVC era. Less commonly used in modern .NET Core projects. (2008), Unity (2008). Each provided different ways to wire abstractions to implementations. The problem: no standard. Every framework used a different container, making it hard to share libraries across projects.

ASP.NET Core 1.0 shipped with a built-in DI container (Microsoft.Extensions.DependencyInjection) — the first Microsoft web framework to make DIP a first-class citizenBefore ASP.NET Core, DI in ASP.NET MVC was possible but required third-party containers and manual plumbing. ASP.NET Core made DI the default — controllers, middleware, filters, and services all receive dependencies via constructor injection out of the box. You can't build an ASP.NET Core app without using DI.. Controllers, middleware, filters, and Razor Pages all receive dependencies via constructor injection. The framework itself uses DIP internally — IWebHostBuilder, IApplicationBuilder, ILogger are all abstractions with swappable implementations.

.NET 8 added keyed servicesA .NET 8 feature that lets you register multiple implementations of the same interface with different string keys. Inject with [FromKeyedServices("key")] attribute. Use case: IPaymentGateway with "stripe" and "paypal" keys — resolve the right one based on runtime context. — the ability to register multiple implementations of the same interface with different keys. This solved a long-standing limitation where you needed third-party containers (Autofac, Scrutor) to distinguish between multiple implementations. Now the built-in container supports [FromKeyedServices("key")] for constructor injection of specific implementations.

// .NET 8 Keyed Services — multiple implementations, same interface
builder.Services.AddKeyedScoped<IPaymentGateway, StripeGateway>("stripe");
builder.Services.AddKeyedScoped<IPaymentGateway, PayPalGateway>("paypal");
builder.Services.AddKeyedScoped<IPaymentGateway, SquareGateway>("square");

// Inject a specific one:
public class CheckoutService([FromKeyedServices("stripe")] IPaymentGateway gateway)
{
    // Gets StripeGateway specifically
}

// Or resolve dynamically:
public class PaymentRouter(IServiceProvider sp)
{
    public IPaymentGateway GetGateway(string provider) =>
        sp.GetRequiredKeyedService<IPaymentGateway>(provider);
}

DIP is the foundation of Clean ArchitectureAn architecture pattern by Robert C. Martin where dependencies point inward — outer layers (Infrastructure, UI) depend on inner layers (Application, Domain), never the reverse. The Domain layer has zero external dependencies. DIP is the mechanism that makes this dependency direction possible.. The dependency rule: source code dependencies must point inward. Inner layers (Domain, Application) define interfaces. Outer layers (Infrastructure, Presentation) implement them.

// PROJECT STRUCTURE — dependency arrows point INWARD

// MyApp.Domain (innermost — NO external references)
//   ├── Entities/        (Order, Product, Customer)
//   ├── Interfaces/      (IOrderRepository, IPaymentGateway)
//   └── ValueObjects/    (Money, Email, Address)

// MyApp.Application (depends on Domain only)
//   ├── Commands/        (CreateOrderCommand, ICreateOrderHandler)
//   ├── Queries/         (GetOrderQuery, IGetOrderHandler)
//   └── Services/        (OrderProcessor — uses Domain interfaces)

// MyApp.Infrastructure (depends on Domain + Application)
//   ├── Persistence/     (SqlOrderRepository : IOrderRepository)
//   ├── External/        (StripePaymentGateway : IPaymentGateway)
//   └── DependencyInjection.cs  (registers all implementations)

// MyApp.WebApi (depends on Application — NOT Infrastructure directly)
//   ├── Controllers/     (OrdersController — depends on ICreateOrderHandler)
//   └── Program.cs       (composition root — wires everything)

// The INTERFACES live in Domain (inner layer)
// The IMPLEMENTATIONS live in Infrastructure (outer layer)
// Dependency arrows: Infrastructure → Domain ← Application
// This IS the Dependency Inversion Principle at the architecture level

MediatRA popular .NET library by Jimmy Bogard that implements the Mediator pattern. Instead of controllers depending on services directly, they send IRequest objects to MediatR, which routes them to the right IRequestHandler. This is DIP in action: the controller depends on the IMediator abstraction, not on any specific handler. is DIP applied to command/query handling. Controllers don't depend on service classes — they depend on IMediator, which routes requests to handlers. Each handler depends on domain interfaces, not infrastructure.

// Controller depends on IMediator (abstraction), not on handlers
[ApiController, Route("api/orders")]
public class OrdersController(IMediator mediator) : ControllerBase
{
    [HttpPost]
    public async Task<IActionResult> Create(CreateOrderRequest request) =>
        Ok(await mediator.Send(new CreateOrderCommand(request.Items)));
}

// Command + Handler — handler depends on domain interfaces
public record CreateOrderCommand(List<OrderItem> Items) : IRequest<int>;

public class CreateOrderHandler(
    IOrderRepository repo,
    IPaymentGateway payment,
    ILogger<CreateOrderHandler> logger) : IRequestHandler<CreateOrderCommand, int>
{
    public async Task<int> Handle(CreateOrderCommand cmd, CancellationToken ct)
    {
        var order = Order.Create(cmd.Items);
        await payment.ChargeAsync(order.Total, order.PaymentToken);
        await repo.SaveAsync(order);
        logger.LogInformation("Order {Id} created", order.Id);
        return order.Id;
    }
}

// DIP chain: Controller → IMediator → IRequestHandler → IOrderRepository
// Every link depends on an abstraction. Zero concrete coupling.

EF Core's DbContext is itself an abstraction over the database. The debate: should you add another abstraction (IRepository) on top? The answer depends on your architecture.

// OPTION A: DbContext IS the abstraction (pragmatic)
// Pro: Less code, EF is already testable (in-memory provider)
// Con: Business logic coupled to EF's API (LINQ, DbSet, SaveChanges)
public class OrderService(AppDbContext db)
{
    public async Task<Order?> GetAsync(int id) => await db.Orders.FindAsync(id);
}

// OPTION B: Repository wraps DbContext (DIP-compliant)
// Pro: Business logic doesn't know about EF, truly swappable
// Con: More code, repository often just proxies DbContext
public class OrderService(IOrderRepository repo)
{
    public async Task<Order?> GetAsync(int id) => await repo.GetByIdAsync(id);
}

// RECOMMENDATION:
// - Small apps / CRUD-heavy: Option A. DbContext is good enough.
// - Domain-heavy / complex business logic: Option B. The repository
//   translates between domain models and EF entities.
// - Libraries / shared packages: ALWAYS Option B. You can't force
//   consumers to use a specific ORM.

IHttpClientFactoryA .NET factory abstraction for creating HttpClient instances. It handles DNS rotation, connection pooling, and lifetime management. Instead of creating new HttpClient() directly (which causes socket exhaustion), inject IHttpClientFactory and call CreateClient(). This is DIP for HTTP — business code depends on the factory abstraction, not on HttpClient construction details. is DIP for HTTP calls. Instead of new HttpClient() scattered through business code, you depend on the factory abstraction. Named/typed clients keep configuration in the composition root.

// ❌ DIP violation — business code creates HttpClient directly
public class WeatherService
{
    private readonly HttpClient _client = new() { BaseAddress = new Uri("https://api.weather.com") };
    // Socket exhaustion risk, DNS caching issues, can't test
}

// ✅ DIP-compliant — typed client with factory
public class WeatherService(HttpClient client)  // Injected by IHttpClientFactory
{
    public async Task<Weather?> GetAsync(string city) =>
        await client.GetFromJsonAsync<Weather>($"/v1/current?q={city}");
}

// Registration in Program.cs:
builder.Services.AddHttpClient<WeatherService>(client =>
{
    client.BaseAddress = new Uri("https://api.weather.com");
    client.Timeout = TimeSpan.FromSeconds(10);
})
.AddPolicyHandler(HttpPolicyExtensions
    .HandleTransientHttpError()
    .WaitAndRetryAsync(3, retry => TimeSpan.FromSeconds(Math.Pow(2, retry))));

// Configuration, retry policies, and HTTP details all in the composition root
// WeatherService knows nothing about base URLs, timeouts, or retry logic

ASP.NET Core Identity is a masterclass in DIP. The identity framework depends on abstractions (IUserStore<T>, IRoleStore<T>, IPasswordHasher<T>) — and you can swap every component.

// ASP.NET Core Identity — every component is an abstraction
builder.Services.AddIdentity<AppUser, IdentityRole>()
    .AddEntityFrameworkStores<AppDbContext>()  // IUserStore → EF implementation
    .AddDefaultTokenProviders();               // IUserTwoFactorTokenProvider → defaults

// Want to store users in MongoDB instead of SQL?
builder.Services.AddIdentity<AppUser, IdentityRole>()
    .AddMongoDbStores<AppUser, IdentityRole, Guid>(config);  // Different IUserStore

// Want a custom password hasher (Argon2 instead of PBKDF2)?
builder.Services.AddScoped<IPasswordHasher<AppUser>, Argon2PasswordHasher>();

// Want custom user validation?
builder.Services.AddScoped<IUserValidator<AppUser>, StrictEmailValidator>();

// DIP: Identity framework depends on IUserStore, IPasswordHasher, IUserValidator
// You provide implementations — the framework never knows the details

Think about it like a restaurant. A waiter (the HTTP request) takes your order, hands it to the kitchen, and then clocks out for the night. But the kitchen still needs to look at the order slip (the DbContext) to prepare your food. The problem? When the waiter clocked out, he took the order slip with him and shredded it. The kitchen reaches for the slip and finds nothing — that's ObjectDisposedException.

In this real production incident, an API endpoint created an order in the database, then spun up a background task with Task.Run to send a confirmation email. The background task needed to look up the customer's email address, so it used the same AppDbContext that the controller was injected with. Seems harmless — the context is right there in the closure.

But here's the catch: AppDbContext is registered as Scoped, which means ASP.NET Core creates it at the start of the HTTP request and disposes it when the response is sent. The controller returns Ok(orderId) immediately, the response flies back to the client, and the DI scope closes — disposing the DbContext. Meanwhile, the background thread is still starting up. By the time Task.Run actually executes that FindAsync call, the DbContext is already disposed. The exception was swallowed by the fire-and-forget pattern (_ = Task.Run(...)), so no error appeared in the API response and no one noticed until customers reported missing confirmation emails.

The scariest part: this bug didn't show up in development. The dev machine was fast enough that the background task finished before the scope was disposed. It only appeared under production load where the thread pool was busy and the background task was delayed.

// ❌ DbContext is Scoped — dies when the request ends
public class OrderController : ControllerBase
{
    private readonly AppDbContext _db;
    private readonly IEmailSender _email;

    [HttpPost]
    public async Task<IActionResult> Create(OrderDto dto)
    {
        var order = await _db.Orders.AddAsync(MapToEntity(dto));
        await _db.SaveChangesAsync();

        // Fire-and-forget — _db is disposed by the time this runs!
        _ = Task.Run(async () =>
        {
            var customer = await _db.Customers.FindAsync(order.Entity.CustomerId);
            await _email.SendAsync(customer!.Email, "Order Confirmed", BuildBody(order.Entity));
        });

        return Ok(order.Entity.Id);
    }
}

// ✅ Fix: Use IServiceScopeFactory for background work
public class OrderController : ControllerBase
{
    private readonly AppDbContext _db;
    private readonly IServiceScopeFactory _scopeFactory;

    [HttpPost]
    public async Task<IActionResult> Create(OrderDto dto)
    {
        var order = await _db.Orders.AddAsync(MapToEntity(dto));
        await _db.SaveChangesAsync();
        var orderId = order.Entity.Id;
        var customerId = order.Entity.CustomerId;

        // Create a NEW scope for background work
        _ = Task.Run(async () =>
        {
            using var scope = _scopeFactory.CreateScope();
            var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
            var email = scope.ServiceProvider.GetRequiredService<IEmailSender>();

            var customer = await db.Customers.FindAsync(customerId);
            await email.SendAsync(customer!.Email, "Order Confirmed", BuildBody(orderId));
        });

        return Ok(orderId);
    }
}

Picture two people standing in a hallway, each refusing to go first. "After you." "No, after you." "No, I insist, after you." They stand there forever, blocking everyone. That's exactly what happens with a circular dependency: Service A says "I need Service B to be created first," and Service B says "I need Service A to be created first." Neither can exist without the other already existing, so the DI container tries to create A, which triggers creating B, which triggers creating A again, which triggers creating B again... until the call stack overflows and the application crashes.

In this case, OrderService needed IInventoryService because placing an order requires checking stock. Meanwhile, InventoryService needed IOrderService because inventory adjustments needed to look up order details. Both teams thought they were following DIP perfectly — they were programming to interfaces, using constructor injection, everything by the book. But neither team noticed the cycle because each service was developed independently.

The app worked in unit tests because each service was tested in isolation with mocked dependencies. The cycle only appeared when the real DI container tried to wire everything together at startup. The error message was a StackOverflowException with no useful stack trace — just thousands of repeated frames showing the container trying to resolve the same two types over and over.

The root cause wasn't a DIP problem — it was a design problem. When two services depend on each other, it usually means there's a missing concept between them. In this case, that missing concept was a domain event: "an order was placed." Instead of OrderService calling InventoryService directly, it should publish the fact that something happened, and let interested parties react.

// ❌ Circular dependency — A needs B, B needs A
public class OrderService : IOrderService
{
    public OrderService(IInventoryService inventory) { }
}

public class InventoryService : IInventoryService
{
    public InventoryService(IOrderService orders) { } // Boom! Cycle.
}

// ✅ Fix: Break cycle with MediatR events
public class OrderService : IOrderService
{
    private readonly IMediator _mediator;

    public OrderService(IMediator mediator)
    {
        _mediator = mediator;
    }

    public async Task PlaceOrderAsync(Order order)
    {
        // Instead of calling IInventoryService directly,
        // publish an event that InventoryService handles
        await _mediator.Publish(new OrderPlacedEvent(order));
    }
}

public class ReserveStockHandler : INotificationHandler<OrderPlacedEvent>
{
    private readonly IInventoryRepository _inventory;

    public ReserveStockHandler(IInventoryRepository inventory)
    {
        _inventory = inventory;
    }

    public async Task Handle(OrderPlacedEvent e, CancellationToken ct)
    {
        await _inventory.ReserveStockAsync(e.Order.Items);
    }
}

Imagine a company has a phone directory (the DI container). There's an entry under "Email Department" (the interface IEmailSender) that points to "John's desk" (EmailSender). During testing, the team redirects "Email Department" to a dummy mailbox. But one employee has John's direct extension written on a sticky note and keeps calling him directly. The test team thinks all email is being intercepted, but John is still getting real calls because someone bypassed the directory.

Here's what happened in practice. The team properly registered IEmailSender with AddScoped<IEmailSender, EmailSender>(). All controllers and services used IEmailSender through constructor injection. Tests replaced IEmailSender with a fake that discarded emails. Everything looked clean.

But somewhere in the codebase, someone also added builder.Services.AddScoped<EmailSender>() — registering the concrete class directly. And a middleware was resolving GetRequiredService<EmailSender>() (the concrete type, not the interface). This created two completely separate registrations in the container. When tests replaced IEmailSender with a fake, the concrete EmailSender registration was untouched. The middleware happily used the real email sender, sending actual emails to real customers during integration tests.

The team only noticed when a customer replied to a test email asking "What's this about?" The root cause was that two different developers added the registrations at different times, in different PRs, and neither noticed the duplication.

// Registration — looks correct
builder.Services.AddScoped<IEmailSender, EmailSender>();

// ❌ But ALSO registered the concrete type directly!
builder.Services.AddScoped<EmailSender>();

// Middleware resolves the CONCRETE type, bypassing the interface
app.Use(async (ctx, next) =>
{
    var sender = ctx.RequestServices.GetRequiredService<EmailSender>(); // Concrete!
    // This is NOT the same instance as IEmailSender
    // Tests that replace IEmailSender don't affect this
    await next();
});

// ✅ Fix: ONLY register the interface, never the concrete type
builder.Services.AddScoped<IEmailSender, EmailSender>();
// Do NOT add: builder.Services.AddScoped<EmailSender>();

// Always resolve via the interface
app.Use(async (ctx, next) =>
{
    var sender = ctx.RequestServices.GetRequiredService<IEmailSender>();
    await next();
});

Think of DIP like customs inspection at an airport. The constructor is the front door — every dependency that comes through it gets declared and inspected. But imagine a traveler who goes through customs with an empty suitcase (clean constructor), then pulls contraband out of their coat pocket inside the terminal (using new inside a method). The inspection system never saw it. That's what new SmtpClient("smtp.company.com") is — a smuggled dependency that bypasses the constructor's "customs."

The class looked perfectly DIP-compliant to code reviewers. The constructor took IOrderRepository — an interface, just like the textbook says. But 40 lines into the CompleteAsync method, there was a new SmtpClient("smtp.company.com") hiding in plain sight. This created a hard dependency on a specific SMTP server that nobody could see by looking at the constructor signature.

The test team wrote unit tests that mocked IOrderRepository perfectly. All tests passed. But they couldn't prevent real emails from being sent during testing, because SmtpClient wasn't injected — it was created inside the method. The tests couldn't reach it. Even worse, when the SMTP server changed addresses, this service broke silently because the server name was hardcoded in the new call, not in configuration.

This is one of the sneakiest DIP violations because it passes both code review and unit testing. The class looks DIP-compliant (interfaces in constructor, check!) but behaves like a tightly-coupled monolith (hardcoded infrastructure inside methods, fail!).

public class OrderService
{
    private readonly IOrderRepository _repo; // ✅ Injected

    public OrderService(IOrderRepository repo) => _repo = repo;

    public async Task CompleteAsync(int orderId)
    {
        var order = await _repo.GetByIdAsync(orderId);
        order.Complete();
        await _repo.SaveAsync(order);

        // ❌ Hidden dependency — new() buried inside method
        using var smtp = new SmtpClient("smtp.company.com");
        var msg = new MailMessage("noreply@co.com", order.Email, "Done!", "...");
        await smtp.SendMailAsync(msg);
    }
}

public class OrderService
{
    private readonly IOrderRepository _repo;
    private readonly IEmailSender _email; // ✅ All dependencies injected

    public OrderService(IOrderRepository repo, IEmailSender email)
    {
        _repo = repo;
        _email = email;
    }

    public async Task CompleteAsync(int orderId)
    {
        var order = await _repo.GetByIdAsync(orderId);
        order.Complete();
        await _repo.SaveAsync(order);

        await _email.SendAsync(order.Email, "Done!", "...");
    }
}

Imagine you're cooking a recipe, but instead of a clear ingredient list at the top, the recipe just says "Go to the pantry." You start cooking, and in step 3 it says "grab flour from the pantry." Step 7 says "grab sugar from the pantry." Step 12 says "grab that obscure spice you might not have." You can't prepare ingredients ahead of time because you don't know what you need until you're mid-recipe. That's what the Service Locator does — it replaces a clear ingredient list (constructor injection) with "just ask the pantry (IServiceProvider) whenever you need something."

A developer on the team had read about DIP and understood the idea of "don't create your own dependencies." So they injected IServiceProvider into every class and used GetRequiredService<T>() inside methods whenever they needed something. Technically, no class was using new to create dependencies. Technically, everything came from the DI container. The developer genuinely believed this was proper DIP.

The problem was invisible at first but grew into a maintenance nightmare. When a new developer tried to write tests for InvoiceService, they looked at the constructor: just IServiceProvider. "Easy, I'll mock that." But what should the mock return? To find out, they had to read every line of every method to discover the 4 hidden dependencies scattered across 500 lines. Miss one, and the test crashes with a NullReferenceException at runtime.

Even worse, when someone removed IBlobStorage from the DI container (during a refactor), the compiler didn't catch it. The app compiled perfectly. The bug only appeared when a user actually triggered the invoice generation code path, weeks after the refactor. With constructor injection, the compiler would have caught it immediately — you can't create an InvoiceService without providing an IBlobStorage.

// ❌ Service Locator — hides real dependencies
public class InvoiceService
{
    private readonly IServiceProvider _sp;

    public InvoiceService(IServiceProvider sp) => _sp = sp;

    public async Task GenerateAsync(int orderId)
    {
        // What does this class ACTUALLY need? Nobody knows without reading every line
        var repo = _sp.GetRequiredService<IOrderRepository>();
        var pdf = _sp.GetRequiredService<IPdfGenerator>();
        var storage = _sp.GetRequiredService<IBlobStorage>();
        var email = _sp.GetRequiredService<IEmailSender>();
        // ... hidden dependencies scattered across 500 lines
    }
}

// ✅ Explicit constructor injection — dependencies are visible
public class InvoiceService
{
    private readonly IOrderRepository _repo;
    private readonly IPdfGenerator _pdf;
    private readonly IBlobStorage _storage;
    private readonly IEmailSender _email;

    public InvoiceService(
        IOrderRepository repo,
        IPdfGenerator pdf,
        IBlobStorage storage,
        IEmailSender email)
    {
        _repo = repo;
        _pdf = pdf;
        _storage = storage;
        _email = email;
    }

    public async Task GenerateAsync(int orderId)
    {
        var order = await _repo.GetByIdAsync(orderId);
        var document = await _pdf.CreateAsync(order);
        var url = await _storage.UploadAsync(document);
        await _email.SendAsync(order.CustomerEmail, "Invoice", url);
    }
}

Replace infrastructure implementations with lightweight in-memory versions. Great for testing multi-class workflows without hitting real databases or APIs.

// A fake that implements the same interface as SqlOrderRepository
public class InMemoryOrderRepository : IOrderRepository
{
    private readonly List<Order> _orders = [];
    private int _nextId = 1;

    public Task<Order?> GetByIdAsync(int id)
        => Task.FromResult(_orders.FirstOrDefault(o => o.Id == id));

    public Task SaveAsync(Order order)
    {
        if (order.Id == 0) order.Id = _nextId++;
        _orders.RemoveAll(o => o.Id == order.Id);
        _orders.Add(order);
        return Task.CompletedTask;
    }
}

// In test setup — swap real DB for in-memory fake
services.AddScoped<IOrderRepository, InMemoryOrderRepository>();

Test the entire HTTP pipeline with selected dependencies swapped out. WebApplicationFactoryA test fixture from Microsoft.AspNetCore.Mvc.Testing that boots your entire ASP.NET Core app in-memory. You can override DI registrations to swap real infrastructure (databases, APIs) with fakes while keeping everything else real — middleware, routing, model binding, authentication. boots your app in-memory and lets you override DI registrations.

public class OrderApiTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public OrderApiTests(WebApplicationFactory<Program> factory)
    {
        _client = factory.WithWebHostBuilder(builder =>
        {
            builder.ConfigureServices(services =>
            {
                // Remove real payment gateway, add fake
                services.RemoveAll<IPaymentGateway>();
                services.AddScoped<IPaymentGateway, FakePaymentGateway>();

                // Use EF In-Memory instead of SQL Server
                services.RemoveAll<DbContextOptions<AppDbContext>>();
                services.AddDbContext<AppDbContext>(o => o.UseInMemoryDatabase("test"));
            });
        }).CreateClient();
    }

    [Fact]
    public async Task POST_Orders_Returns201()
    {
        var response = await _client.PostAsJsonAsync("/api/orders", new { Amount = 50m });
        Assert.Equal(HttpStatusCode.Created, response.StatusCode);
    }
}

Catch missing registrations, lifetime mismatches, and circular dependencies before the app handles any traffic.

var builder = WebApplication.CreateBuilder(args);

// Enable DI validation in Development
if (builder.Environment.IsDevelopment())
{
    builder.Host.UseDefaultServiceProvider(options =>
    {
        options.ValidateScopes = true;   // Default in Dev since ASP.NET Core 2.0
        options.ValidateOnBuild = true;  // Opt-in: catches missing registrations at startup
    });
}

// Unit test: verify ALL interfaces can be resolved
[Fact]
public void AllServices_CanBeResolved()
{
    var factory = new WebApplicationFactory<Program>();
    using var scope = factory.Services.CreateScope();

    // This will throw if any registration is missing or circular
    var orderProcessor = scope.ServiceProvider.GetRequiredService<IOrderProcessor>();
    Assert.NotNull(orderProcessor);
}

Calling a method through an interface uses virtual dispatchWhen calling a method on an interface or virtual method, the CLR looks up the actual implementation in a vtable (virtual method table) at runtime. This adds one pointer dereference (~1ns) compared to a direct call. The JIT compiler can sometimes devirtualize these calls when it proves only one implementation exists. — one extra pointer lookup (~1ns). The JIT often devirtualizes these when it can prove only one implementation exists (which is common in DI scenarios). When the JIT sees that only one class implements IOrderRepository in your app, it can prove the call target at compile time and inline the method directly — eliminating virtual dispatch entirely.

Verdict: Unmeasurable in business applications. Only matters in ultra-hot paths (game engines, allocators, parsers processing millions of items per second).

DIP enables performance optimizations that are impossible without it:

• Caching decorators: Wrap IProductRepository with a CachedProductRepository — zero changes to business logic
• Connection pooling: IHttpClientFactory manages HttpClient lifetimes and DNS changes — your code just calls IOrderApi
• Lazy loading: Inject Lazy<IExpensiveService> to defer initialization until first use
• Swapping implementations: Switch from EF Core to Dapper for read-heavy queries by changing one DI line

Verdict: DIP's performance cost is negligible. Its performance benefit — enabling optimizations without touching business code — is significant.

MediatR's IPipelineBehavior<TRequest, TResponse> is DIP applied to cross-cutting concerns. Each behavior wraps the next like middlewareA software component that forms a pipeline, where each component can process a request before/after passing it to the next component. ASP.NET Core HTTP middleware, MediatR pipeline behaviors, and Express.js middleware all follow this pattern. Each layer adds cross-cutting concern without modifying the core handler. — logging, validation, caching, and transactions, all without modifying business handlers.

// Validation behavior — runs BEFORE every command handler
public class ValidationBehavior<TRequest, TResponse>
    : IPipelineBehavior<TRequest, TResponse>
    where TRequest : IRequest<TResponse>
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
        => _validators = validators;

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken ct)
    {
        var failures = _validators
            .Select(v => v.Validate(request))
            .SelectMany(r => r.Errors)
            .Where(f => f != null)
            .ToList();

        if (failures.Count != 0)
            throw new ValidationException(failures);

        return await next(); // Call the actual handler
    }
}

// Register — applies to ALL commands automatically
builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));

The pipeline execution order: Logging → Validation → Caching → Transaction → Handler. Each behavior depends only on the IPipelineBehavior abstraction and RequestHandlerDelegate — pure DIP.

IHttpClientFactoryIntroduced in .NET Core 2.1 to solve HttpClient's DNS and socket exhaustion problems. Instead of new HttpClient() (which holds sockets open), the factory manages HttpMessageHandler lifetimes and pools connections. It also supports typed clients, named clients, and Polly-based resilience policies. is a masterclass in DIP. Your business code depends on a typed client interface — the factory handles connection pooling, DNS rotation, and resilience policies behind the scenes.

// Domain — your interface
public interface IWeatherApi
{
    Task<WeatherForecast?> GetForecastAsync(string city);
}

// Infrastructure — typed client implementation
public class WeatherApiClient : IWeatherApi
{
    private readonly HttpClient _http;

    public WeatherApiClient(HttpClient http) => _http = http;

    public async Task<WeatherForecast?> GetForecastAsync(string city)
        => await _http.GetFromJsonAsync<WeatherForecast>($"/forecast/{city}");
}

// Program.cs — configure with resilience
builder.Services.AddHttpClient<IWeatherApi, WeatherApiClient>(client =>
{
    client.BaseAddress = new Uri("https://api.weather.com");
    client.DefaultRequestHeaders.Add("ApiKey", builder.Configuration["Weather:Key"]);
})
.AddStandardResilienceHandler(); // Retry, circuit breaker, timeout — automatic

Extract an interface from the dependency. Add it as a constructor parameter. For backward compatibility during migration, provide a default constructorA temporary migration technique: the original parameterless constructor creates the concrete instance (preserving existing behavior), while a new constructor accepts the interface (enabling DI). Once all callers use DI, remove the default constructor. This is NOT recommended long-term — it's a migration bridge only. that creates the concrete implementation.

// Step 2a: Extract interface
public interface IOrderDataAccess
{
    Task<Order?> GetByIdAsync(int id);
}

// Step 2b: Wrap existing code as implementation
public class SqlOrderDataAccess : IOrderDataAccess
{
    public async Task<Order?> GetByIdAsync(int id)
    {
        using var conn = new SqlConnection("...");
        // Move existing SQL code here
    }
}

// Step 2c: Add constructor injection (keep backward compat temporarily)
public class ReportService
{
    private readonly IOrderDataAccess _dataAccess;

    // Migration constructor — existing callers still work
    public ReportService() : this(new SqlOrderDataAccess()) { }

    // DI constructor — new callers and tests use this
    public ReportService(IOrderDataAccess dataAccess)
    {
        _dataAccess = dataAccess;
    }
}

Once all callers use the DI container, register the service and remove the parameterless constructor. The migration is complete for this dependency. Repeat for the next seam.

// Program.cs — register
builder.Services.AddScoped<IOrderDataAccess, SqlOrderDataAccess>();
builder.Services.AddScoped<ReportService>();

// ReportService — remove the migration constructor
public class ReportService
{
    private readonly IOrderDataAccess _dataAccess;

    public ReportService(IOrderDataAccess dataAccess)
    {
        _dataAccess = dataAccess;
    }
    // Parameterless constructor is GONE — DIP is enforced
}

// Now you can test ReportService with a mock
[Fact]
public async Task Generate_ReturnsReport()
{
    var mockData = new Mock<IOrderDataAccess>();
    mockData.Setup(d => d.GetByIdAsync(1)).ReturnsAsync(testOrder);

    var service = new ReportService(mockData.Object);
    var result = await service.GenerateAsync(1);
    Assert.NotNull(result);
}

Once interfaces are extracted, move them to the Domain/Application project and implementations to Infrastructure. This enforces DIP at the project reference level — if Infrastructure references Domain but Domain doesn't reference Infrastructure, developers physically can't violate DIP.

// Final project structure
MyApp.Domain/              → Interfaces + Entities (ZERO external dependencies)
MyApp.Application/         → Business logic (references: Domain only)
MyApp.Infrastructure/      → Implementations (references: Domain + NuGet packages)
MyApp.WebApi/              → Entry point (references: Application + Infrastructure)

// Project references enforce DIP:
// Domain ← Application ← WebApi → Infrastructure → Domain
// Infrastructure CAN'T be referenced by Domain (compilation error)