ServiceFilter and TypeFilter differences in .NET
Today in this article, we will understand ServiceFilter and TypeFilter differences in .NET.
In .NET Core, both ServiceFilter and TypeFilter are used for implementing filters, which are an easy way to address any cross-cutting concerns to the execution pipeline of an application.
There are many benefits of Filters as explained below,
Benefits of Filters
- Abstract your repetitive and important cross-cutting concern to commonplace.
- Make your business logic free of addressing those concerns implicitly
- As we know “Code is more often read than write”. The code becomes easy to read and understand.
- Developers can better focus on implementing business functionality.
While they serve a similar purpose, there are some differences between ServiceFilter and TypeFilter
When to Use Scenarios
ServiceFilter: This Filter can be applied to a service or middleware during dependency injection. It allows applying the same filter to multiple services or middleware components.
TypeFilter: This Filter directly to a controller or action method i.r classes and methods, providing more fine-grained control over which specific components the filter is applied to.
Reusability of Filter
ServiceFilter – Better Reusability
ServiceFilter provides flexibility and reusability because it can be applied to multiple services or interfaces.
You can register a filter as a service and then apply it to multiple services during dependency injection configuration.
This allows you to define a filter once and reuse it in multiple places.
TypeFilter – Normal Reusability
TypeFilter is more specific to individual classes or methods.
It is typically used when you need to apply a filter to a specific class or method and do not require its reuse in other parts of the application.
Filter Configuration
ServiceFilter
Since the ServiceFilter uses the ServiceProvider to resolve the instance of the filter. Instance lifetime can be controlled by registering the filter in the startup class.
ServiceFilter can be registered as a service in the dependency injection container using the AddScoped, AddTransient, or AddSingleton methods.
public void ConfigureServices(IServiceCollection services)
{
// Add service filters.
services.AddScoped<AddHeaderResultServiceFilter>();
services.AddScoped<SampleActionFilterAttribute>();
.
.
}
The registered filter can then be applied to services or middleware components by specifying the filter using the [ServiceFilter] attribute or the .AddServiceFilter() method.
Example :
[ServiceFilter(typeof(SampleActionFilterAttribute))]
public IActionResult ServiceFilterTest()
{
return Content($"From ServiceFilterTest");
}
Dependency Injection of additional parameters
ServiceFilter allows you to inject additional parameters into the filter constructor when applying it at the service registration level.
These additional parameters can be resolved from the dependency injection container and provided to the filter constructor.
TypeFilter supports the constructor injection of additional parameters through attributes.
You can pass parameters to the filter by providing them as arguments in the attribute declaration.
Example
[TypeFilter(typeof(CustomFilter), Arguments = new object[] { "id", 123 })].
These parameters are then passed to the filter’s constructor.
Summary
ServiceFilter is used to apply filters at the service registration level in the startup class and while TypeFilter is used to apply filters directly to specific classes or methods.
The choice between ServiceFilter and TypeFilter depends on whether you need to apply a filter globally to services/interfaces or selectively to individual classes/methods.
Service filter allows greater reusability and flexibility comapre to TypeFilter.
Do you have any comments or ideas or any better suggestions to share?
Please sound off your comments below.
Happy Coding !!
Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published(2024) best practices and guidelines for software design and development.
