Dependency Injection (DI) in C# is a design pattern that enhances modularity, testability, and maintainability by allowing classes to receive dependencies externally. 1. DI promotes loose coupling by decoupling object creation from usage. 2. It simplifies testing through mock object injection. 3. Components become more reusable across applications. 4. Changes in dependencies don’t require widespread code changes. In ASP.NET Core, DI is integrated into the framework, primarily using constructor injection. Services are registered in Program.cs or Startup.cs, for example: builder.Services.AddTransient();. Then, they are injected into classes via constructors. ASP.NET Core supports three service lifetimes: 5. Transient — created each time they’re requested. 6. Scoped — created once per request, ideal for database contexts. 7. Singleton — created once and reused. Choosing the correct lifetime is crucial to avoid issues like state sharing. For instance, Entity Framework DbContexts should be scoped to prevent concurrency problems. While the built-in DI container is sufficient for many scenarios, especially in smaller projects, it lacks advanced features such as property injection and interception. In such cases, developers may opt for third-party containers like Autofac or Unity. Overall, DI in ASP.NET Core enables clean dependency management, but requires careful handling of lifetimes and registration patterns to ensure application stability and performance.

Dependency Injection (DI) is a design pattern that helps make applications more modular, testable, and maintainable. At its core, DI allows classes to receive their dependencies from an external source rather than creating them internally. This makes it easier to swap out implementations, write unit tests, and manage complex object graphs.

In C#, especially within ASP.NET Core, DI is built into the framework and used extensively throughout the application lifecycle.

Why Use Dependency Injection?

There are a few solid reasons why DI has become such a standard practice:

• Loose Coupling: Your classes don’t need to know how to create or manage their own dependencies.
• Easier Testing: You can inject mock objects during testing instead of real ones.
• Reusability: Components can be reused across different parts of the app or even different projects.
• Maintainability: If something changes in a dependency, you don't have to rewrite every place it's used.

For example, if you're working with a service that logs data to a database, using DI means you can switch between logging to SQL Server, MongoDB, or even a file without changing your main logic — just by swapping out the injected implementation.

How Does Built-in DI Work in ASP.NET Core?

ASP.NET Core comes with a built-in lightweight DI container. It supports constructor injection out of the box, which is the most common way to use DI in the framework.

You typically register services in the Startup.cs or Program.cs file depending on whether you're using the older or newer project templates.

Here’s how you register a service:

// In Program.cs (for .NET 6  minimal APIs)
var builder = WebApplication.CreateBuilder(args);

// Register services here
builder.Services.AddTransient<IMyService, MyService>();

Then, you can use it in a controller like this:

public class MyController : ControllerBase
{
    private readonly IMyService _myService;

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

    [HttpGet]
    public IActionResult Get()
    {
        var result = _myService.DoSomething();
        return Ok(result);
    }
}

The framework handles resolving the correct instance of IMyService at runtime based on how you've registered it.

Service Lifetimes: Transient, Scoped, Singleton

When registering services, you also choose how long they live. The three main options are:

• Transient: Created each time they're requested. Best for lightweight, stateless services.
• Scoped: Created once per client request (HTTP request in web apps). Good for things like database contexts.
• Singleton: Created the first time they’re requested and then reused for all subsequent requests.

Choosing the right lifetime matters. For example, injecting a transient service into a singleton might cause issues because the transient could carry state that shouldn’t be shared.

Let’s say you're using Entity Framework Core. You'd normally register your DbContext as scoped:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

That ensures the context lives only for the duration of the HTTP request and avoids concurrency problems.

When Not to Use the Built-in DI Container

While the built-in DI works well for most scenarios, it's not the most feature-rich container out there. If you find yourself needing advanced features like:

• Property injection
• Auto-registration
• Interception or decorators

You might consider replacing it with a third-party container like Autofac, Unity, or Microsoft.Extensions.DependencyInjection with some extensions.

But for many projects — especially smaller to mid-sized ones — the built-in system is perfectly fine.

So, basically, DI in C# via ASP.NET Core gives you a clean way to manage dependencies without tight coupling. You register services, inject them where needed, and let the framework handle the rest. It's not overly complex, but it does require understanding lifetimes and how the container resolves types.

The above is the detailed content of What is Dependency Injection (DI), and how can it be implemented in C# (e.g., using built-in DI in ASP.NET Core)?. For more information, please follow other related articles on the PHP Chinese website!