Dependency injection in a controller allows the framework to supply required services, enhancing testability and maintainability. 1. Use constructor injection by declaring dependencies in the constructor parameters. 2. Register services in startup files like Program.cs with appropriate lifetimes such as AddScoped. 3. Avoid property injection unless necessary as it obscures dependencies. 4. Utilize built-in DI features for logging and configuration, maintaining focus on handling HTTP requests within controllers.

When you're working with a controller in a framework like ASP.NET Core or Spring, using dependency injection (DI) is a clean way to get the services your controller needs without hard-coding them. You simply declare what dependencies you need in the constructor, and the framework handles creating and passing them in for you.

Here’s how to do it properly and avoid common pitfalls.

Understand What Dependency Injection Is in a Controller

In simple terms, dependency injection in a controller means letting someone else (the framework's DI container) give you the tools (services, repositories, etc.) you need instead of creating them yourself inside the controller.

This keeps your code testable, maintainable, and loosely coupled.

For example:

• Your controller might need a service that fetches user data from a database.
• Instead of instantiating that service manually, you just ask for it in the constructor.
• The framework will then inject an instance automatically.

Use Constructor Injection (The Preferred Method)

Most modern frameworks like ASP.NET Core and Spring MVC recommend constructor injection. Here’s how it works:

You define a constructor in your controller that takes one or more interfaces or concrete types as parameters. The framework resolves those dependencies when it creates the controller.

public class UserController : ControllerBase
{
    private readonly IUserService _userService;

    public UserController(IUserService userService)
    {
        _userService = userService;
    }

    [HttpGet("{id}")]
    public async Task<IActionResult> GetUser(int id)
    {
        var user = await _userService.GetUserByIdAsync(id);
        return Ok(user);
    }
}

What's happening here:

• IUserService is an interface you've defined somewhere else.
• The actual implementation (like UserService) is registered with the DI container.
• When a request hits this controller, the framework knows which concrete service to pass in.

This approach is preferred because:

• It makes dependencies explicit.
• It makes unit testing easier—you can pass mock objects directly into the constructor during tests.

Register Services Properly in Startup

Just declaring dependencies in the controller isn’t enough. You also have to register them in the application's startup so the DI system knows how to resolve them.

In ASP.NET Core, this usually happens in the Startup.cs file or in Program.cs if you're using .NET 6 .

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

// Register services here
builder.Services.AddScoped<IUserService, UserService>();

var app = builder.Build();

Key points:

• Make sure the lifetime matches your use case: AddTransient, AddScoped, or AddSingleton.
• Don't forget to register both the interface and the implementation.
• If you skip this step, you'll get runtime errors about not being able to resolve the service.

Avoid Property Injection Unless Necessary

Some frameworks support property injection, where you decorate a property with an attribute like [Inject] or [Autowired]. While it can work, it's generally discouraged unless you have a specific reason.

Why?

• It hides dependencies—someone reading your code won’t see what’s needed just by looking at the constructor.
• It makes testing harder because you can’t easily provide those dependencies when instantiating the controller manually.

Stick with constructor injection unless you're dealing with legacy systems or third-party components that force property injection.

Bonus Tip: Use Built-in Logging or Configuration via DI

You don’t always have to create your own services to use DI. Most frameworks already provide useful ones out of the box.

For example, in ASP.NET Core, you can inject ILogger<T> directly:

private readonly ILogger<UserController> _logger;

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

Or inject configuration options like this:

public UserController(IOptions<ApiSettings> settings)
{
    var timeout = settings.Value.DefaultTimeout;
}

These are great examples of how DI helps keep your controllers focused on handling HTTP requests rather than managing internal logic or config.

That’s basically how you use dependency injection in a controller. It's straightforward once you understand how to wire things up in the startup and structure your constructor correctly.

The above is the detailed content of How do I use dependency injection in a controller?. For more information, please follow other related articles on the PHP Chinese website!