I am interested in interceptor concept in recent times. I know that this concept is used in many libraries like NHibernate, Entity Framework and others. But i am interested in how to use this concept in ASP.NET MVC web application.
Where it is usefull to use it in Mvc Web application?
Is there any open source Asp.Net Mvc project which use interceptors ?
Asp.net Mvc already support a kind of interceptor for controller with filters. It is better to use filters instead of interceptors ?
Interception can be used for many things - most notable to address cross-cutting concerns such as instrumentation, logging, auditing, security, metering, etc.
You don't need a DI Container to apply the concept, but it helps.
You can use ASP.NET MVC filters to achieve roughly the same effect, but why constrain yourself to the MVC framework when you can apply a generally reusable implementation?
I would say you use a more generic DI container for injecting your dependencies. Not only does this inject dependencies into your controller, it also serves the dependencies of those dependencies thus resulting in a complete object graph of all your dependant objects.
Using a DI container for the front end also brings nice opportunities for making your back end more unit testable and loosly coupled.
Where/when to use interceptors
Take a look at a previous application you've developed and examine the code. Look for code that is frequently duplicated at the beginning or end of methods and properties. This is code that you may consider moving from all of those methods into an interceptor. For example, I've noticed that many of my MVC actions that perform input validation do so with same same couple lines of code:
This is code that could potentially be moved to an interceptor (probably an MVC filter in this case). Does the cost of writing and applying the filter outweigh the cost of this duplicated code? (2 lines of code times the number of controller actions using this). In this case, perhaps not. There are other situations, however, where the benefit of using an interceptor would be greater.
Here's a list of some situations where I imagine this type of code duplication might occur, i.e. scenarios that smell like they could benefit from interceptors:
AuthorizeAttribute
is a filter for exactly this.Thread.Sleep
when necessary.Dispose
a WCF client if it's in theFaulted
state, so every method that creates and destroys an instance of the client needs to check the state, then callAbort
if necessary instead of simply wrapping ausing
clause around the client. An interceptor might not be the best fit in this case. It's probably easier to just fix theDispose
implementation or use some kind of wrapper.Whether or not the above examples would be good candidates for interceptors depends on the unique intricacies of your application. This list of course is not exhaustive, nor can it be. The possible applications of interceptors are as varied as the applications you write.
How to use interceptors
I can think of three primary places where you might like to apply an interceptor: Controllers, Services, and Domain objects.
The nitty gritty details about how to accomplish all of this will depend on which tools you are using.