C# Constructor Dependency Injection: Guide with Examples

Constructor Dependency Injection (CDI) in C# is a powerful technique for creating more flexible, testable, and maintainable code. Here's what you need to know:

CDI involves passing dependencies to a class through its constructor
It reduces coupling between components and improves modularity
CDI makes unit testing easier by allowing mock objects to be injected

Key benefits of using CDI:

Clear dependencies: Constructor parameters show exactly what a class needs
Guaranteed initialization: All dependencies are set up when the object is created
Immutability: Dependencies can't be changed after object creation

Quick example:

public class OrderProcessor
{
    private readonly IPaymentGateway _paymentGateway;

    public OrderProcessor(IPaymentGateway paymentGateway)
    {
        _paymentGateway = paymentGateway;
    }

    public void ProcessOrder(Order order)
    {
        _paymentGateway.ProcessPayment(order.Total);
    }
}

This guide covers:

Basics of CDI
Implementation steps
Advanced techniques
Common issues and solutions
Using DI containers
Performance considerations

By the end, you'll be able to effectively use CDI to improve your C# projects.

Basics of Constructor Dependency Injection

Constructor Dependency Injection (CDI) in C# is all about making your code flexible and easy to test. Here's how it works:

How Constructor Injection works

With CDI, you pass dependencies to a class through its constructor. Check out this example:

public class OrderProcessor
{
    private readonly IOrderRepository _repository;

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

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

Here, OrderProcessor needs an IOrderRepository. Instead of creating one itself, it asks for one in its constructor. This makes the class more flexible and testable.

Why Use Constructor Injection?

CDI has some big perks:

You can see what a class needs just by looking at its constructor.
All required dependencies are set up when the object is created.
Once set, dependencies can't be changed, which can prevent bugs.
It's easy to swap in mock objects for unit tests.

Different Types of Dependency Injection

Let's compare CDI with other types:

Type	How it Works	When to Use	Pros	Cons
Constructor	Pass in constructor	Required dependencies	Clear, guaranteed setup	Can be messy with many dependencies
Property	Set via public properties	Optional dependencies	Flexible, changeable	Might leave object in bad state
Method	Pass to specific methods	Method-specific needs	Very flexible	Can clutter method signatures

Constructor injection is often the best choice for its clarity and reliability. But each type has its place, depending on what you need.

What you need to know before starting

Before diving into Constructor Dependency Injection (CDI) in C#, let's cover the essentials:

C# and .NET basics

You'll need to know:

OOP concepts (classes, interfaces, inheritance)
C# syntax (method declarations, access modifiers)
SOLID principles, especially Dependency Inversion

Here's a quick interface example:

public interface ILogger
{
    void Log(string message);
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

Required software and setup

To get started:

Tool	Purpose	Version (2023)
.NET SDK	Build and run C# apps	.NET 6.0+
IDE	Write and debug code	VS 2022 or VS Code with C# extension
NuGet	Manage dependencies	Included with VS

Optional: DI container and unit testing framework.

Setup steps:

Download .NET SDK
Install VS or VS Code with C# extension
Create a new C# project

Now you're ready to implement CDI in your C# projects.

How to implement Constructor Injection

Here's how to set up Constructor Injection in C#:

Create interfaces for dependencies

Define your dependency interfaces:

public interface ILogger
{
    void Log(string message);
}

public interface IDataAccess
{
    string GetData(int id);
}

Implement the interfaces

Now, create classes that use these interfaces:

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

public class DatabaseAccess : IDataAccess
{
    public string GetData(int id)
    {
        return $"Data for ID {id}";
    }
}

Use dependencies in a constructor

Create a class that uses these dependencies:

public class EmployeeService
{
    private readonly ILogger _logger;
    private readonly IDataAccess _dataAccess;

    public EmployeeService(ILogger logger, IDataAccess dataAccess)
    {
        _logger = logger;
        _dataAccess = dataAccess;
    }

    public string GetEmployeeData(int id)
    {
        _logger.Log($"Fetching data for employee {id}");
        return _dataAccess.GetData(id);
    }
}

EmployeeService now depends on ILogger and IDataAccess. We inject these through the constructor. This makes the class more flexible and easier to test.

To use this class:

var logger = new ConsoleLogger();
var dataAccess = new DatabaseAccess();
var employeeService = new EmployeeService(logger, dataAccess);

string data = employeeService.GetEmployeeData(1);

This setup lets you swap implementations easily. For example, you could use a FileLogger instead of ConsoleLogger without changing EmployeeService.

Advantage	Description
Testability	Mock dependencies for unit testing
Flexibility	Swap implementations easily
Clarity	Dependencies are obvious in the constructor

Tips for using Constructor Injection

Constructor Injection in C# is great, but you need to use it right. Here's how:

Keep constructors simple

Make your constructors do ONE thing: assign dependencies. No complex logic or heavy lifting.

public class UserService
{
    private readonly IUserRepository _userRepository;
    private readonly ILogger _logger;

    public UserService(IUserRepository userRepository, ILogger logger)
    {
        _userRepository = userRepository;
        _logger = logger;
    }
}

This makes your code easier to read, test, and maintain.

Avoid circular dependencies

Circular dependencies? Bad news. They can break your code at runtime. Here's how to fix them:

Redesign your classes
Use a factory pattern
Use a temporary null state

Here's an example:

public class Site
{
    private ILoginStrategy _loginStrategy;

    public Site() { }

    public void SetLoginStrategy(ILoginStrategy loginStrategy)
    {
        _loginStrategy = loginStrategy;
    }
}

public class LoginStrategyA : ILoginStrategy
{
    private readonly Site _site;

    public LoginStrategyA(Site site)
    {
        _site = site;
    }
}

// Usage
var site = new Site();
var loginStrategy = new LoginStrategyA(site);
site.SetLoginStrategy(loginStrategy);

Use default implementations

Default implementations make your life easier. They're great for testing and optional dependencies.

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

public class DefaultEmailService : IEmailService
{
    public void SendEmail(string to, string subject, string body)
    {
        // Default implementation
    }
}

public class NotificationService
{
    private readonly IEmailService _emailService;

    public NotificationService(IEmailService emailService = null)
    {
        _emailService = emailService ?? new DefaultEmailService();
    }
}

Advanced Constructor Injection techniques

Constructor Injection can get tricky. Here's how to handle complex scenarios:

Managing many dependencies

Too many dependencies? Your class might be doing too much. Here's how to fix it:

Split the class
Use a factory
Group related dependencies

Instead of this:

public class UserService(
    IUserRepository userRepo,
    IEmailService emailService,
    ILogger logger,
    IAuthenticator auth,
    IPaymentProcessor payment)
{
    // ...
}

Try this:

public class UserService(
    IUserRepository userRepo,
    INotificationService notificationService,
    IAuthenticationService authService)
{
    // ...
}

It's easier to manage and test.

Dealing with optional dependencies

For dependencies you don't always use:

Use nullable types
Provide default implementations

Here's an example:

public class ValidationPipeline<TRequest>
{
    private readonly IValidator<TRequest>? _validator;

    public ValidationPipeline(IValidator<TRequest>? validator = null)
    {
        _validator = validator;
    }

    public async Task<TResponse> Handle(TRequest request)
    {
        if (_validator != null)
        {
            // Perform validation
        }
        // Process request
    }
}

This pipeline works with or without a validator.

Mixing different injection types

Sometimes you need to mix Constructor Injection with other types:

Property Injection: For optional, changeable dependencies
Method Injection: When a dependency is needed for a specific method

Example:

public class ReportGenerator
{
    private readonly IDataSource _dataSource;
    public IFormatter? Formatter { get; set; } // Property Injection

    public ReportGenerator(IDataSource dataSource)
    {
        _dataSource = dataSource;
    }

    public void GenerateReport(IReportType reportType) // Method Injection
    {
        var data = _dataSource.GetData();
        var formattedData = Formatter?.Format(data) ?? data;
        reportType.Generate(formattedData);
    }
}

This gives you flexibility while keeping core dependencies in the constructor.

Common problems and solutions

CDI is great, but it's not without its challenges. Let's look at some common issues and how to fix them.

Too many injected dependencies

When your constructor looks like a grocery list, it's time to rethink. Here's why it's bad:

It breaks the Single Responsibility Principle
It's a nightmare to maintain
It makes unit testing a pain

How to fix it:

1. Split the class

Break it into smaller, focused classes. For example:

// Before
public class Employee(string name, string address, int age, string department, 
    decimal salary, IEmailService emailService, IPayrollService payrollService)
{
    // ...
}

// After
public class Employee(PersonalInfo personalInfo, EmploymentInfo employmentInfo, 
    IEmailService emailService)
{
    // ...
}

public class PersonalInfo(string name, string address, int age)
{
    // ...
}

public class EmploymentInfo(string department, decimal salary, IPayrollService payrollService)
{
    // ...
}

2. Use the Builder pattern 3. Introduce Parameter Objects

Multiple constructor issues

Multiple constructors can cause:

Confusion
Maintenance headaches
Bugs

The fix:

1. Stick to one constructor when you can 2. Use optional parameters for less important stuff

Here's how:

public class Logger(ILogStorage storage, IFormatter? formatter = null)
{
    private readonly IFormatter _formatter = formatter ?? new DefaultFormatter();

    // ...
}

3. Consider the Factory pattern for complex objects

Incorrect use of DI containers

DI containers are powerful, but easy to misuse. Common mistakes:

Resolving dependencies in the wrong place
Creating circular dependencies
Overusing singletons

To use them right:

1. Resolve dependencies at the entry point

Like this:

public class Program
{
    public static void Main(string[] args)
    {
        var services = new ServiceCollection();
        services.AddTransient<IUserRepository, UserRepository>();
        services.AddTransient<IEmailService, EmailService>();
        services.AddTransient<UserService>();

        var serviceProvider = services.BuildServiceProvider();

        var userService = serviceProvider.GetRequiredService<UserService>();
        userService.RegisterUser("john@example.com");
    }
}

2. Watch out for circular dependencies 3. Use the right lifetimes for your objects

Testing with Constructor Injection

Constructor Injection makes unit testing easy. Here's how to use it:

Using mocks for unit tests

Mocking isolates the class you're testing. Here's the process:

Create interfaces for dependencies
Use a mocking framework for fake objects
Inject mocks into your class's constructor

Example using Moq for C#:

[TestClass]
public class BookServiceTests
{
    private BookService _bookService;
    private Mock<IBookRepository> _mockBookRepository;
    private Mock<IBookEntityDomainAdapter> _mockBookEntityDomainAdapter;

    [TestInitialize]
    public void TestInitialize()
    {
        _mockBookRepository = new Mock<IBookRepository>();
        _mockBookEntityDomainAdapter = new Mock<IBookEntityDomainAdapter>();
        _bookService = new BookService(_mockBookRepository.Object, _mockBookEntityDomainAdapter.Object);
    }

    [TestMethod]
    public void GetAll_ItemsInRepository_ReturnsSameNumberOfItems()
    {
        // Arrange
        var sampleData = Enumerable.Repeat(new BookEntity(), 5).ToList();
        _mockBookRepository.Setup(x => x.GetAll()).Returns(sampleData);

        // Act
        var result = _bookService.GetAll();

        // Assert
        Assert.AreEqual(sampleData.Count(), result.Count());
    }
}

This test sets up mocks, injects them into BookService, and tests the GetAll method.

Testing tools and methods

To improve your testing:

Use mocking frameworks like Moq, NSubstitute, or FakeItEasy
Run tests with NUnit, xUnit, or MSTest
Set up CI pipelines for automatic testing
Measure coverage with dotCover or OpenCover
Use factory methods for setup:

private BookService CreateUnitUnderTest(
    Mock<IBookRepository> mockRepo = null,
    Mock<IBookEntityDomainAdapter> mockAdapter = null)
{
    mockRepo ??= new Mock<IBookRepository>();
    mockAdapter ??= new Mock<IBookEntityDomainAdapter>();
    return new BookService(mockRepo.Object, mockAdapter.Object);
}

This approach makes tests more readable and maintainable.

Practical examples

Let's dive into real-world uses of Constructor Injection in C# with code samples.

E-commerce order processing

Here's how Constructor Injection can streamline an order processing system:

public class OrderProcessor
{
    private readonly IDatabase _database;
    private readonly IPaymentGateway _paymentGateway;
    private readonly IEmailService _emailService;

    public OrderProcessor(IDatabase database, IPaymentGateway paymentGateway, IEmailService emailService)
    {
        _database = database;
        _paymentGateway = paymentGateway;
        _emailService = emailService;
    }

    public void ProcessOrder(Order order)
    {
        _database.SaveOrder(order);
        _paymentGateway.ProcessPayment(order.Total);
        _emailService.SendOrderConfirmation(order);
    }
}

This setup makes it a breeze to swap components. Want to change payment gateways? No problem. Need a new email service? Easy peasy.

Logging in a web application

Logging is everywhere in web apps. Here's how Constructor Injection makes it simple:

public class UserController
{
    private readonly ILogger _logger;
    private readonly IUserService _userService;

    public UserController(ILogger logger, IUserService userService)
    {
        _logger = logger;
        _userService = userService;
    }

    public IActionResult Register(UserRegistrationModel model)
    {
        try
        {
            _userService.RegisterUser(model);
            _logger.LogInformation($"User {model.Email} registered successfully");
            return Ok();
        }
        catch (Exception ex)
        {
            _logger.LogError($"Error registering user {model.Email}: {ex.Message}");
            return BadRequest();
        }
    }
}

Want to switch logging implementations? Go for it. Need to add new logging targets? No sweat.

Notification system

Let's look at a notification system using Constructor Injection:

public interface IMessageService
{
    void SendMessage(string message);
}

public class EmailService : IMessageService
{
    public void SendMessage(string message)
    {
        Console.WriteLine($"Sending email: {message}");
    }
}

public class SMSService : IMessageService
{
    public void SendMessage(string message)
    {
        Console.WriteLine($"Sending SMS: {message}");
    }
}

public class NotificationService
{
    private readonly IMessageService _messageService;

    public NotificationService(IMessageService messageService)
    {
        _messageService = messageService;
    }

    public void SendNotification(string message)
    {
        _messageService.SendMessage(message);
    }
}

public class Program
{
    public static void Main()
    {
        IMessageService emailService = new EmailService();
        NotificationService emailNotification = new NotificationService(emailService);
        emailNotification.SendNotification("Your order has been shipped!");

        IMessageService smsService = new SMSService();
        NotificationService smsNotification = new NotificationService(smsService);
        smsNotification.SendNotification("Your package has arrived!");
    }
}

See how NotificationService works with different message services? That's the power of Constructor Injection. It's flexible, extensible, and just plain cool.

Using DI containers

DI containers simplify dependency management in C# projects. They handle dependency creation and injection, which is especially useful for large applications.

Popular C# DI containers

Here's a quick look at some widely-used C# DI containers:

Container	Key Features
Unity	Lightweight, extensible, multiple injection types
Autofac	Flexible config, good performance, modular
Simple Injector	Fast, easy to use, promotes best practices
Ninject	Portable, supports AOP, extensible

Setting up containers for Constructor Injection

Let's see how to set up and use some popular DI containers:

1. Unity

After installing Unity:

var container = new UnityContainer();
container.RegisterType<IEmailService, EmailService>();
container.RegisterType<IPaymentGateway, PaymentGateway>();

var orderProcessor = container.Resolve<OrderProcessor>();

2. Autofac

With Autofac installed:

var builder = new ContainerBuilder();
builder.RegisterType<EmailService>().As<IEmailService>();
builder.RegisterType<PaymentGateway>().As<IPaymentGateway>();
builder.RegisterType<OrderProcessor>();

var container = builder.Build();
var orderProcessor = container.Resolve<OrderProcessor>();

3. Simple Injector

True to its name, Simple Injector is straightforward:

var container = new Container();
container.Register<IEmailService, EmailService>();
container.Register<IPaymentGateway, PaymentGateway>();
container.Register<OrderProcessor>();

var orderProcessor = container.GetInstance<OrderProcessor>();

When using these containers:

Register dependencies before resolving objects
Keep the container in your composition root
Use the container for top-level objects only

Performance impact

DI in C# can affect your app's performance. Here's what you need to know:

App startup

DI can slow down startup, especially in big apps. Why? It takes time to set up and manage all those dependencies.

Want to measure startup time in ASP.NET Core? Use the ServerReady event from Microsoft.AspNetCore.Hosting.

Different service lifetimes impact startup differently:

Service Type	Startup Impact
Singleton	Highest
Scoped	Medium
Transient	Lowest

Singletons are created at startup. This can make initial load slower, but might speed things up later.

Memory use and object lifecycles

How you manage object lifecycles with DI affects memory use. Check it out:

Service Type	Memory Usage	Response Time
Singleton	20MB	10ms
Scoped	50MB	20ms
Transient	100MB	15ms

Want to keep memory use in check?

Use singletons for services that don't change
Cache expensive dependencies
Be careful with scoped services in web apps

"The memory DI uses is tiny compared to other parts of the system, especially in web apps where ASP.NET creates lots of temporary objects per request."

DI itself doesn't eat up much memory. But if you implement it poorly, you might run into issues.

Watch out: In Entity Framework, keeping a DbContext alive too long can cause bugs and memory leaks.

To avoid DI performance problems:

Profile your app to spot memory issues
Keep an eye on DI performance when lots of users hit your app at once
Mix and match service lifetimes based on what your app needs

Fixing common issues

CDI can be tricky. Here's how to tackle common problems:

Common errors and fixes

1. Constructor Over-Injection

When a class has too many dependencies:

public class SuperOrderProcessor
{
    public SuperOrderProcessor(
        IOrderValidator validator,
        IPaymentProcessor paymentProcessor,
        IInventoryManager inventoryManager,
        IShippingService shippingService,
        IEmailSender emailSender,
        ILogger logger)
    {
        // ...
    }
}

Fix: Split it into smaller, focused classes.

2. Circular Dependencies

Two classes depending on each other? That's a no-go.

Fix: Redesign. Extract a common interface both can use.

3. Service Registration Issues

Weird behavior? Might be registration problems.

Fix: Debug by accepting an IEnumerable<>:

public MyService(IEnumerable<ISayHello> sayHello) {}

4. Release vs. Debug Build Differences

Works in Debug, fails in Release? Dependency resolution might be the culprit.

Fix: Add a parameterless constructor:

public class MyService
{
    public MyService() { }
    public MyService(IDependency dependency) { }
}

5. Autofac Setup Mistakes

Outdated Autofac config in ASP.NET Core? That's trouble.

Fix: Use this setup:

builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());
builder.Host.ConfigureContainer<ContainerBuilder>(containerBuilder => {
    containerBuilder.RegisterType<MyDependency>().SingleInstance();
});

Debugging advice

Set breakpoints in constructors.
Double-check your DI registrations.
Remove dependencies one by one to isolate issues.
Log your DI container setup.
Use TryAdd* to avoid duplicate registrations:

services.TryAddSingleton<IMyService, MyService>();

Keep constructors simple. Use Initialize() for complex setup:

public class ExampleServer
{
    private readonly ISocketFactory _socketFactory;

    public ExampleServer(ISocketFactory socketFactory)
    {
        _socketFactory = socketFactory;
    }

    public void Start()
    {
        var socket = _socketFactory.CreateSocket();
        // Use the socket...
    }
}

Conclusion

Constructor Dependency Injection (CDI) in C# boosts code quality and maintainability. Here's why it's useful:

Cuts down coupling between components
Makes your code more flexible and testable
Encourages interface use, improving modularity

Check out this CDI example:

public class OrderProcessor
{
    private readonly IPaymentGateway _paymentGateway;
    private readonly IInventoryManager _inventoryManager;

    public OrderProcessor(IPaymentGateway paymentGateway, IInventoryManager inventoryManager)
    {
        _paymentGateway = paymentGateway;
        _inventoryManager = inventoryManager;
    }

    public void ProcessOrder(Order order)
    {
        _paymentGateway.ProcessPayment(order.Total);
        _inventoryManager.UpdateStock(order.Items);
    }
}

This setup makes testing and tweaking OrderProcessor a breeze.

Want to use CDI in your C# projects? Here's how:

Spot dependencies in your classes
Create interfaces for them
Refactor classes to accept dependencies via constructors
Use a DI container to handle object creation

Try Microsoft's DI container:

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IPaymentGateway, StripePaymentGateway>();
    services.AddSingleton<IInventoryManager, DatabaseInventoryManager>();
    services.AddScoped<OrderProcessor>();
}

This sets up your dependencies for automatic resolution by the DI container.

FAQs

How to use dependency injection in constructor C#?

Here's how to use constructor dependency injection in C#:

Define interfaces for your dependencies
Create classes that implement these interfaces
In your target class, add a constructor that takes these interfaces as parameters
Use a DI container to handle dependency resolution