Part 17: Service Registration in ASP.NET Core Dependency Injection

In the previous article, we introduced what dependency injection (DI) is and how it helps reduce coupling between components while improving code maintainability. Now, we’ll dive deeper into how to register and manage services in the ASP.NET Core framework. Understanding service registration is a critical part of the DI mechanism.

Core Concepts of Dependency Injection

In ASP.NET Core, the core of dependency injection revolves around services and the container. A service is a class that implements some functionality, while the container is responsible for instantiating and managing the lifecycle of those services. By registering services with the container, the system can automatically inject them wherever needed.

Service Registration

In ASP.NET Core, service registration typically occurs in the ConfigureServices method of the Startup class. We use the IServiceCollection interface to register services. Below is a simplified example demonstrating how to register a service:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddTransient<IMyService, MyService>();
        // ... other service registrations
    }
}

In the code above, we register the interface IMyService along with its concrete implementation MyService. There are several registration methods available:

• AddTransient: Creates a new instance each time the service is requested.
• AddScoped: Creates one instance per request scope (e.g., per HTTP request).
• AddSingleton: Creates a single instance for the entire application lifetime.

Service Lifetimes

Choosing the appropriate service lifetime is crucial for application performance and memory usage. Typical use cases for each lifetime are as follows:

• Transient: Best suited for stateless or lightweight services that do not need to preserve state across requests.
• Scoped: Ideal for services that must share state throughout a single request—such as database context interactions.
• Singleton: Appropriate for state shared across the entire application, commonly used for configuration objects or infrequently changing data.

Example: Registering a Service

Suppose we have a simple email service interface and its implementation:

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

public class EmailService : IEmailService
{
    public void SendEmail(string to, string subject, string body)
    {
        // Actual email-sending logic
        Console.WriteLine($"Sending Email to {to} with subject {subject}");
    }
}

We can register this service in the Startup class like so:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddScoped<IEmailService, EmailService>();
    }
}

Using Registered Services

Registered services can be consumed via constructor injection in controllers or other services. For example:

public class HomeController : Controller
{
    private readonly IEmailService _emailService;

    public HomeController(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public IActionResult SendMail()
    {
        _emailService.SendEmail("user@example.com", "Hello", "This is a test email.");
        return Ok("Email sent!");
    }
}

In this controller, IEmailService is automatically injected at construction time, allowing us to use _emailService directly to send emails.

Summary

By registering services, we effectively manage their lifetimes and enable dependency injection—enhancing code maintainability and testability. In the next article, we’ll demonstrate how to use registered services in real-world ASP.NET Core applications to implement business logic and conduct unit testing. We hope this article has provided you with a solid understanding—and that you’ll apply these concepts confidently in your own projects.