If you have ever created your own Action Filter in ASP.NET Core, you are probably aware of the existance of the
ServiceFilterAttribute. But did you know that there exists also a
TypeFilterAttribute? In this post, I'll explain both types and show you the differences between the two.
Action Filters that are implemented as attributes and added directly to controller classes or action methods cannot have constructor dependencies provided by dependency injection (DI). This is because attributes must have their constructor parameters supplied where they're applied.
Therefore ASP.NET Core provides two out-of-the-box attributes that can make your action filters DI enabled:
The ServiceFilter attribute allows us to specify the type of our action filter and have it automatically resolve the class from the built-in DI container. This means that we can implement our action filter to accept dependencies directly via the constructor:
You should register the filter with the correct lifetime in the DI container:
On your controller classes or action methods you can now add the ServiceFilter attribute:
TypeFilterAttribute is very similar to the
ServiceFilterAttribute (and also implements IFilterFactory), but its type is not resolved directly from the DI container. Instead, it instantiates the type by using
Because of this difference, types that are referenced using the
TypeFilterAttribute do not need to be registered with the container first. This means that when using a
TypeFilter, it is possible to provide the constructor parameters yourself (through the
Here is an example (that inspired me for this post) I encountered during a code review:
In the example above, an inherited class is created from the
TypeFilterAttribute. This is not necessary, and you can also use it directly(I had to change the filter implementation a little bit):