Dependency Inversion Principle (DIP) in C#: Depend on Abstractions

CustomerService now depends on ICustomerRepository . Switch databases by injecting a different implementation. No changes to CustomerService .

The Logging Dependency

This pattern appears everywhere:

  
    public class PaymentProcessor
{
    public void ProcessPayment(Payment payment)
    {
        try
        {
            // Process payment
            Console.WriteLine("Payment processed successfully");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Payment failed: {ex.Message}");
        }
    }
}
  

PaymentProcessor is coupled to console logging. Want file logging? Modify the class. Want database logging? Modify again.

DIP Solution

  
    public interface ILogger
{
    void LogInfo(string message);
    void LogError(string message, Exception ex);
}

public class ConsoleLogger : ILogger
{
    public void LogInfo(string message)
    {
        Console.WriteLine($"[INFO] {message}");
    }

    public void LogError(string message, Exception ex)
    {
        Console.WriteLine($"[ERROR] {message}: {ex.Message}");
    }
}

public class FileLogger : ILogger
{
    private readonly string _filePath;

    public FileLogger(string filePath)
    {
        _filePath = filePath;
    }

    public void LogInfo(string message)
    {
        File.AppendAllText(_filePath, $"[INFO] {DateTime.Now}: {message}
");
    }

    public void LogError(string message, Exception ex)
    {
        File.AppendAllText(_filePath, $"[ERROR] {DateTime.Now}: {message} - {ex.Message}
");
    }
}

public class PaymentProcessor
{
    private readonly ILogger _logger;

    public PaymentProcessor(ILogger logger)
    {
        _logger = logger;
    }

    public void ProcessPayment(Payment payment)
    {
        try
        {
            // Process payment
            _logger.LogInfo("Payment processed successfully");
        }
        catch (Exception ex)
        {
            _logger.LogError("Payment processing failed", ex);
        }
    }
}
  

PaymentProcessor depends on ILogger , not concrete implementations.

Dependency Injection Patterns

DIP is implemented through dependency injection. Three main patterns:

Constructor Injection (Recommended)

  
    public class OrderService
{
    private readonly IOrderRepository _repository;
    private readonly ILogger _logger;

    public OrderService(IOrderRepository repository, ILogger logger)
    {
        _repository = repository;
        _logger = logger;
    }
}
  

Dependencies are required and immutable. Clear and testable.

Property Injection

  
    public class OrderService
{
    public IOrderRepository Repository { get; set; }
    public ILogger Logger { get; set; }
}
  

Optional dependencies or when constructor injection isn't feasible. Less preferred because dependencies aren't guaranteed.

Method Injection

  
    public class OrderService
{
    public void ProcessOrder(Order order, ILogger logger)
    {
        // Use logger
    }
}
  

When dependency varies per method call. Rarely used.

IoC Containers

Inversion of Control (IoC) containers automate dependency injection:

  
    // Program.cs or Startup.cs
services.AddTransient();
services.AddScoped();
services.AddSingleton();

// Automatic injection
public class CustomerController
{
    private readonly ICustomerRepository _repository;
    private readonly ILogger _logger;

    // Container automatically injects dependencies
    public CustomerController(ICustomerRepository repository, ILogger logger)
    {
        _repository = repository;
        _logger = logger;
    }
}
  

Popular containers: Microsoft.Extensions.DependencyInjection, Autofac, Unity.

The Testing Advantage

DIP makes testing trivial:

  
    // Without DIP - hard to test
public class OrderService
{
    private SqlOrderRepository _repository = new SqlOrderRepository();

    public void SaveOrder(Order order)
    {
        _repository.Save(order); // Hits real database!
    }
}

// With DIP - easy to test
public class OrderService
{
    private readonly IOrderRepository _repository;

    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }

    public void SaveOrder(Order order)
    {
        _repository.Save(order);
    }
}

// Test with mock
[Test]
public void SaveOrder_ValidOrder_CallsRepository()
{
    // Arrange
    var mockRepo = new Mock();
    var service = new OrderService(mockRepo.Object);
    var order = new Order();

    // Act
    service.SaveOrder(order);

    // Assert
    mockRepo.Verify(r => r.Save(order), Times.Once);
}
  

DIP and the Other Principles

DIP ties all SOLID principles together:

DIP + SRP: When classes have single responsibilities and depend on abstractions, the system is modular and flexible.

DIP + OCP: Abstractions make code open for extension. Add new implementations without modifying high-level code.

DIP + LSP: Abstractions only work if implementations are properly substitutable. LSP ensures DIP works correctly.

DIP + ISP: Small, focused interfaces make dependency injection cleaner. Classes don't drag in unused dependencies.

Common Pitfalls

1. Abstracting Everything

  
    // Overkill
public interface IDateTime
{
    DateTime Now { get; }
}
  

Don't abstract stable framework classes unless you truly need to control them (e.g., for testing).

2. Leaky Abstractions

  
    // Bad - exposes SQL details
public interface IUserRepository
{
    SqlDataReader ExecuteQuery(string sql);
}
  

Abstractions shouldn't leak implementation details.

3. Service Locator Anti-Pattern

  
    // Bad - hidden dependency
public class OrderService
{
    public void ProcessOrder()
    {
        var repo = ServiceLocator.Get();
    }
}
  

Use constructor injection instead. Dependencies should be explicit.

When NOT to Apply DIP

• Stable, simple classes – If a class rarely changes and has no dependencies, abstraction adds complexity

• Framework types – Don't abstract string , DateTime , etc.

• Private utility methods – Internal helpers don't need abstraction

Conclusion

The Dependency Inversion Principle is the culmination of SOLID. By depending on abstractions rather than concrete implementations, you create flexible, testable, maintainable systems. High-level business logic becomes independent of low-level implementation details.

DIP isn't about eliminating dependencies—it's about controlling them. By inverting the direction of dependencies, you gain control over how components interact, making your architecture adaptable to change.

When you find yourself instantiating concrete classes with new inside high-level code, pause. Ask: "Should I depend on an abstraction here?" More often than not, the answer is yes.

Congratulations! You've completed the SOLID principles series. You now have powerful tools for designing maintainable, flexible C# applications. Apply these principles consistently, and you'll write code that stands the test of time.

Key Takeaways

• ✅ Depend on abstractions – Use interfaces and abstract classes, not concrete implementations

• ✅ Invert dependencies – High-level and low-level modules both depend on abstractions

• ✅ Constructor injection – Preferred method for providing dependencies

• ✅ IoC containers – Automate dependency management in large applications

• ✅ Testability – DIP makes unit testing trivial through mocking

• ✅ Flexibility – Swap implementations without changing high-level code

• ✅ Avoid over-abstraction – Abstract where it adds value, not everywhere

• ✅ Completes SOLID – DIP ties all principles together into a cohesive design philosophy

How has DIP changed your architecture? Share your experiences below!

References and Further Reading

• Previous in series: Interface Segregation Principle (ISP) in C#

• Series overview: SOLID Principles in C#: Building Software That Lasts