Dependency injection in dotnet with examples

Dependency Injection (DI) is a design pattern in software development where the components of a system do not create their dependencies directly but are instead passed their dependencies from an external source. In other words, DI is a technique for achieving Inversion of Control (IoC), where the control over object creation and lifecycle management is moved outside the class that uses these objects.

Why do we use dependency injection?

There are several benefits to using Dependency Injection:

Decoupling:

You reduce the coupling between components by injecting dependencies into a class rather than creating them internally. This makes your code more modular and easier to maintain.

Step-by-Step Example

Define Interfaces

First, define interfaces for the services that your application will depend on. This helps in creating loosely coupled components.

// ILoggerService.cs
public interface ILoggerService
{
    void Log(string message);
}

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

Implement Interfaces

Next, create concrete implementations of these interfaces.

// LoggerService.cs
public class LoggerService : ILoggerService
{
    public void Log(string message)
    {
        Console.WriteLine($"Log entry: {message}");
    }
}

// EmailService.cs
public class EmailService : IEmailService
{
    public void SendEmail(string to, string subject, string body)
    {
        // Simulate sending an email
        Console.WriteLine($"Sending email to {to}, subject: {subject}, body: {body}");
    }
}

ILoggerService and IEmailService define the contracts, LoggerService and EmailService implement these contracts. This setup allows for different implementations if needed, without changing the consumer class NotificationService.

Create a Consumer Class

Create a class that depends on the services. Instead of instantiating these services directly, it will receive them through DI.

// NotificationService.cs
public class NotificationService
{
    private readonly ILoggerService _loggerService;
    private readonly IEmailService _emailService;

    public NotificationService(ILoggerService loggerService, IEmailService emailService)
    {
        _loggerService = loggerService;
        _emailService = emailService;
    }

    public void Notify(string to, string subject, string body)
    {
        _emailService.SendEmail(to, subject, body);
        _loggerService.Log("Email sent successfully.");
    }
}

NotificationService depends on ILoggerService and IEmailService, but it does not create instances of these services. Instead, it receives them through its constructor.

Configure Dependency Injection

In your Program.cs or Startup.cs (depending on the type of .NET application), configure the DI container to inject the dependencies.

// Program.cs
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();

        var notificationService = host.Services.GetRequiredService<NotificationService>();
        notificationService.Notify("example@example.com", "Test Subject", "Test Body");
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureServices((context, services) =>
            {
                services.AddTransient<ILoggerService, LoggerService>();
                services.AddTransient<IEmailService, EmailService>();
                services.AddTransient<NotificationService>();
            });
}

The CreateHostBuilder method configures the DI container, specifying that whenever ILoggerService or IEmailService is required, instances of LoggerService , and EmailService should be provided. NotificationService itself is registered so that it can receive its dependencies.

By using DI, NotificationService is decoupled from the concrete implementations of ILoggerService and IEmailService. This promotes flexibility, testability, and maintainability in your application.

Testability:

DI makes unit testing easier because you can substitute real dependencies with mock or stub objects during testing. This allows you to isolate and test individual components of your application.

Example (using a mocking framework like Moq):

[TestMethod]
public void TestEmailSuccess()
{
    var mockEmailService = new Mock<EmailService>();
    var userService = new NotificationService(mockEmailService.Object);

    userService.Notify("test@example.com","Test Subject", "Email body");

    mockEmailService.Verify(es => es.SendEmail(It.IsAny<string>(), It.IsAny<string>()), Times.Once);
}

Flexibility:

With DI, you can easily swap out dependencies with different implementations. For example, you might switch between a production database and an in-memory database for testing purposes without changing the code that uses these dependencies.

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

public class FileLogger : ILogger
{
    public void Log(string message)
    {
        // Log message to a file
    }
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        // Log message to the console
    }
}

public class CustomerService
{
    private readonly ILogger _logger;

    // Constructor injection
    public CustomerService(ILogger logger)
    {
        _logger = logger;
    }

    public void AddCustomer(string name)
    {
        _logger.Log($"Adding customer: {name}");
        // Add customer logic
    }
}

Here, CustomerService depends on an ILogger interface, and different implementations (FileLogger, ConsoleLogger) can be injected based on the requirement or configuration.

Do we need interfaces for dependency injection in .net?

In .NET, using interfaces for dependency injection (DI) is a common practice, but it is not strictly necessary. The primary goal of DI is to decouple the creation of an object from its dependencies, which can be achieved in multiple ways. Here’s a breakdown of when and why you might use interfaces for DI, as well as alternatives:

Benefits of Using Interfaces for Dependency Injection

1. Decoupling: Interfaces help decouple your classes from their dependencies, making your code more modular and easier to maintain. This decoupling allows more flexibility in changing implementations without affecting the dependent code.
2. Testability: Interfaces enable easier unit testing because you can create mock implementations of interfaces to test your classes in isolation.
3. Flexibility: Using interfaces allows you to switch implementations easily. For example, you might have different implementations for a service (e.g., a mock service for testing and a real service for production).
4. Abstraction: Interfaces provide a clear contract that implementations must adhere to, which can improve code readability and enforce consistent behavior across different implementations.

When Interfaces Might Not Be Necessary

1. Simple Applications: In small or simple applications where the overhead of creating interfaces might outweigh the benefits, you might choose to inject concrete classes directly.
2. Concrete Dependencies: If a dependency is unlikely to have multiple implementations, using an interface might be overkill. For instance, a utility class that performs a specific function and is unlikely to change could be injected directly.
3. Framework-Level Dependencies: Some frameworks and libraries provide abstractions that might make custom interfaces redundant. For instance, ASP.NET Core’s built-in services might be sufficient for your needs without additional interfaces.

Alternatives to Interfaces

1. Abstract Classes: If you have a base class with shared functionality that other classes inherit, you can use an abstract class instead of an interface. This is useful to provide some default behavior or shared code.
2. Direct Injection: You can inject concrete classes directly if you are sure that no other implementations are needed. This approach is simpler but less flexible for future changes.
3. Delegates/Func: In some scenarios, you can use delegates or Func to inject behavior. This is particularly useful for injecting small pieces of behavior without creating full interfaces or classes.

Example in .NET Using interfaces for Dependency Injection:

public interface IMyService
{
    void DoWork();
}

public class MyService : IMyService
{
    public void DoWork()
    {
        // Implementation
    }
}

public class MyController
{
    private readonly IMyService _myService;

    public MyController(IMyService myService)
    {
        _myService = myService;
    }

    public void Execute()
    {
        _myService.DoWork();
    }
}

// Registration in ASP.NET Core
services.AddTransient<IMyService, MyService>();

Example in .Net Injecting a concrete class directly for Dependency Injection:

public class MyService
{
    public void DoWork()
    {
        // Implementation
    }
}

public class MyController
{
    private readonly MyService _myService;

    public MyController(MyService myService)
    {
        _myService = myService;
    }

    public void Execute()
    {
        _myService.DoWork();
    }
}

// Registration in ASP.NET Core
services.AddTransient<MyService>();

For the complete source code and more examples, visit the GitHub repository: Dependency Injection In Dotnet With Examples.