🚀 Dependency Injection in ASP.NET Core — Beyond the Basics

Developers are familiar with the basics (like registering services in Startup.cs), many struggle to use it effectively in real-world applications.

In this post, we’ll go beyond the basics and look at advanced techniques, common mistakes, and how to design better, testable, and maintainable .NET applications using DI.

🧱 Quick Recap: What Is Dependency Injection?

Dependency Injection is a design pattern that allows objects to receive their dependencies from an external source rather than creating them internally. In ASP.NET Core, the built-in IoC (Inversion of Control) container manages this for you.

public interface IEmailService

{

    void Send(string to, string subject, string body);

}



public class SmtpEmailService : IEmailService

{

    public void Send(string to, string subject, string body)

    {

        // SMTP logic here

    }

}

// Registering the service

services.AddScoped();

✅ Common Service Lifetimes

ASP.NET Core provides three primary lifetimes:

Singleton: Created once for the application's lifetime

Scoped: Created once per request

Transient: Created every time it's requested

💡 Tip: Avoid using Singleton for services that depend on Scoped dependencies like DbContext. This can lead to runtime exceptions.

⚠️ Anti-Patterns to Avoid

1. Service Locator Pattern
   Using IServiceProvider manually to resolve dependencies is a code smell:

// DON'T DO THIS

public class SomeService

{

    private readonly IServiceProvider _provider;



    public SomeService(IServiceProvider provider)

    {

        _provider = provider;

    }



    public void DoSomething()

    {

        var db = _provider.GetService<MyDbContext>();

    }

}

This hides dependencies, making your code harder to test and maintain.

✅ Better: Use constructor injection instead.

🧪 DI and Unit Testing

One of the biggest benefits of DI is testability.

Let’s say you have a controller that depends on IUserService:

public class UsersController : ControllerBase

{

    private readonly IUserService _userService;



    public UsersController(IUserService userService)

    {

        _userService = userService;

    }



    [HttpGet("{id}")]

    public IActionResult Get(int id)

    {

        var user = _userService.GetUserById(id);

        return Ok(user);

    }

}

You can now easily mock IUserService in a unit test:

var mock = new Mock<IUserService>();

mock.Setup(u => u.GetUserById(1)).Returns(new User { Id = 1, Name = "John" });

var controller = new UsersController(mock.Object);

var result = controller.Get(1);

🧠 Tip: Use Interface Segregation for Better DI

Instead of large interfaces with many methods, split them into smaller, focused interfaces. This makes your services easier to mock and reduces coupling.

🧰 Useful Libraries for DI Enhancements

Scrutor — Adds assembly scanning for service registration

👉 services.Scan(...)

Autofac — More powerful container if you outgrow the built-in one

MediatR — Combine DI with CQRS pattern for better decoupling

✅ Final Thoughts

Dependency Injection is more than just registering services. It’s a mindset that promotes loose coupling, better design, and easier testing.

By avoiding common anti-patterns and leveraging DI features smartly, you can build applications that are easier to maintain and extend over time.

💬 What’s Next?

Want me to dive into Scoped pitfalls in async methods?

Curious about integrating Autofac or Scrutor in a clean architecture project?

Let me know in the comments — and if you found this helpful, consider giving it a ❤️!

📌 Tags:

#dotnet #aspnetcore #dependency-injection #csharp #architecture