A few years ago I blogged about dependency injection directly into actions in ASP.NET Web API. The idea is quite simple - instead of injecting all of your dependencies via the controller’s constructor, you can inject them as parameters into the action handling a given HTTP request.
This can help you prevent over-injection in the constructor; I also like this approach because it’s very verbose and clear - an action explicitly manifests what it needs to handle the request and gets just that, nothing more.
It actually works out of the box in ASP.NET Core, so let’s have a look at that and some related configuration.
The basic idea π
Just in case what we are trying to achieve here is not obvious yet, here is an extremely basic layout of the problem. Let’s imagine having two separate services, with two separate implementations.
public interface IHelloService
{
string SayHello();
}
public class HelloService : IHelloService
{
public string SayHello() => "Hello";
}
public interface IGoodbyeService
{
string SayGoodbye();
}
public class GoodbyeService : IGoodbyeService
{
public string SayGoodbye() => "Bye";
}
For the sake of completeness, let’s also include a basic request DTO. It’s not needed at all, but I want to have it just to be able to illustrate that injecting dependencies as parameters will not interfere with regular binding process.
public class RequestDto
{
public string Name {get; set;}
}
We’d like to consume them in a controller, but rather than doing this
public class GreetController : ApiController
{
private readonly IHelloService _helloService;
private readonly IGoodbyeService _goodbyeService;
public GreetController(IHelloService helloService, IGoodbyeService goodbyeService)
{
_helloService = helloService;
_goodbyeService = goodbyeService;
}
[HttpPost("hello")]
public string Post(RequestDto input)
=> _helloService.SayHello() + " " + input.Name;
[HttpPost("bye")]
public string Post(RequestDto input)
=> _goodbyeService.SayGoodbye() + " " + input.Name;
}
I would want to see the following setup:
[Route("api/[controller]")]
[ApiController]
public class GreetController : ApiController
{
[HttpPost("hello")]
public ActionResult<string> Post(RequestDto input, IHelloService svc)
=> svc.SayHello() + " " + input.Name;
[HttpPost("bye")]
public ActionResult<string> Post(RequestDto input, IGoodbyeService svc)
=> svc.SayGoodbye() + " " + input.Name;
}
Note that the [ApiController] and ActionResult
Injection into actions π
As I mentioned earlier, contrary to i.e. ASP.NET Web API, where we needed to override some internal components to make this, the basic scenario laid out here works out of the box in ASP.NET Core. The only caveat is that you have to decorate the parameter that you’d like to inject (resolve from the DI container) with a [FromServices] attribute.
[HttpPost("hello")]
public ActionResult<string> Post(RequestDto input, [FromServices]IHelloService svc)
=> svc.SayHello() + " " + input.Name;
We could finish the discussion here, as the goal is pretty much achieved. For example, I could issue a following request
```
curl -X POST \
https://localhost:5001/api/greet/hello \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-d '{
"name":"filip"
}'
```
and then get the following response:
Hello filip
However, it is still possible to get rid of the [FromServices] attribute by establishing a reasonable convention. For example, we could easily detect at application startup, when the application model is composed, if a parameter is an interface, and if that’s the case, we would resolve it from the container.
In the past, in ASP.NET Core 2.0, this could be achieved by building an IApplicationModelConvention, registering it, iterating over all discovered controller, then over their actions and then over their parameters, and inspecting those. Then, marking the parameters we’d want to resolve from the DI container with a BindingSource.Services.
This would partially work in ASP.NET Core 2.1 too, however only if you wouldn’t use the new ApiControllerAttribute feature. That feature would validate whether your actions doesn’t inject more than one unannotated complex parameter into an action (which is essentially what we are doing) and throw an exception if that’s the case. That validation happens before our convention would run. The reason for this is that the ApiControllerAttribute feature is implemented as an IApplicationModelProvider which does similar stuff too IApplicationModelConvention - but providers run before the conventions do. So to address that we’d implement a custom provider instead.
public class ActionDependencyModelProvider : IApplicationModelProvider
{
public int Order => -901;
public void OnProvidersExecuted(ApplicationModelProviderContext context)
{
}
public void OnProvidersExecuting(ApplicationModelProviderContext context)
{
foreach (var controllerModel in context.Result.Controllers)
{
foreach(var actionModel in controllerModel.Actions)
{
foreach(var parameterModel in actionModel.Parameters)
{
if (parameterModel.ParameterType.IsInterface)
{
parameterModel.BindingInfo = new BindingInfo()
{
BindingSource = BindingSource.Services
};
}
}
}
}
}
}
Two implementation notes here - I used the Order value of -901 - that’s because the provider responsible for ApiControllerAttribute uses the value -900 and we’d want to run before it. Another thing is that we check for a parameter being an interface to resolve it from the DI container. Of course you are free to establish your own convention here (especially as it’s perfectly reasonable to have non-interface based dependencies). For example you could have a simple convention that 1st parameter would be bound from body and next ones from the container, or a convention where the assembly from which the Type comes dictates whether it’s a request model or a dependency, or simply some naming convention.
You’d just have to register this provider at startup, and that’s it. In our case the Startup registrations now look like this:
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<IHelloService, HelloService>();
services.AddSingleton<IGoodbyeService, GoodbyeService>();
services.TryAddEnumerable(
ServiceDescriptor.Transient<IApplicationModelProvider, ActionDependencyModelProvider>());
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}
And that’s it - you can now use your dependencies exactly as we defined it earlier:
[Route("api/[controller]")]
[ApiController]
public class GreetController : ApiController
{
[HttpPost("hello")]
public ActionResult<string> Post(RequestDto input, IHelloService svc)
=> svc.SayHello() + " " + input.Name;
[HttpPost("bye")]
public ActionResult<string> Post(RequestDto input, IGoodbyeService svc)
=> svc.SayGoodbye() + " " + input.Name;
}
As usually, you can find the full source code here on Github.
