User scoped dependencies in a custom ASP.NET Core Action Filter?

user_2834630 0
Viewed 225

According to the official documentation here:

https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/filters#authorization-filters

To implement a custom ActionFilter in ASP.NET Core I have three choices:

  • SeviceFilterAttribute
  • TypeFilterAttribute
  • IFilterFactory

But for all three it is stated that:

Shouldn't be used with a filter that depends on services with a lifetime other than singleton.

So how can I inject scoped services in my custom ActionFilter? I can easily get a scoped service from the current HttpContext like this:

public override void OnActionExecuting(ActionExecutingContext actionContext)
{
    ISubscriptionHelper subscriptionHelper =
        actionContext.HttpContext.RequestServices
            .GetRequiredService<ISubscriptionHelper>();
}

But then I am wondering if I am doing something wrong? What is the correct way to depend on scoped services in a custom ActionFilterAttribute?

actionfilterattribute asp.net-core custom-action-filter dependency-injection
1 Answers

Resolving services from the HttpContext.RequestServices will correctly resolve scoped and transient instances without causing any problems such as Captive Dependencies. In case resolved components implement IDisposable, they will be disposed of when the request ends. ASP.NET Core passes on the current HttpContext object to filter's OnActionExecuting method and that HttpContext gives access to the DI Container.

This is completely different from injecting those services into the constructor, because the action filter will be cached for the lifetime of the application. Any dependencies stored in private fields will, therefore, live as long as that filter. This leads to the so called Captive Dependency problem.

Code that accesses the DI Container (the HttpContext.RequestServices is your gateway into the DI Container) should be centralized in the infrastructure code of the startup path of the application—the so called Composition Root. Accessing your DI Container outside the Composition Root inevitably leads to the Service Locator anti-pattern—this should not be taken lightly.

To prevent this, it is advised to keep the amount of code inside the action filter as small as possible and implement the filter as a Humble Object. This means that preferably, the only line of code inside the filter is the following:

actionContext.HttpContext.RequestServices
    .GetRequiredService<ISomeService>() // resolve service
    .DoSomeOperation(); // delegate work to service

This means all (application) logic is moved to the ISomeService implementation, allowing the action filter to become a Humble Object.

user_2646970
Related