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 ?

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:

if (!ModelState.IsValid)
    return View(model);

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:

• Input validation (as illustrated above).
• Debug logging. You could write an interceptor that records the entrance and exit of every method call.
• Thread synchronization. Your question is about web apps, but if you're developing a Windows application with an MVP style view, you could apply an interceptor that ensures that all method calls are synchronized back to the UI thread.
• Database transactions. Most of my database transaction code looks like this:

using (var transaction = Session.BeginTransaction())
{
    // ... do some work that is unique to this method ...
    transaction.Commit();
}

• PropertyChanged event implementations. This code is usually very repetitive and annoying to write. Sacha Barber has thoroughly explored how to automatically implement this event using various frameworks.
• Security. There are probably many methods in your application that should be restricted to only certain users. The AuthorizeAttribute is a filter for exactly this.
• Web service request throttling. Some API's, such as the API for Basecamp, ask that you limit your requests to a certain number of requests per a given timeframe. If you wrote a Basecamp client class, you could apply an interceptor to it to ensure that all the method calls honored the speed limit, using Thread.Sleep when necessary.
• Result caching. MVC has some filters pre-built for this purpose. You could write your own interceptor to cache results for layers underneath the UI layer.
• WCF error handling. You can't Dispose a WCF client if it's in the Faulted state, so every method that creates and destroys an instance of the client needs to check the state, then call Abort if necessary instead of simply wrapping a using clause around the client. An interceptor might not be the best fit in this case. It's probably easier to just fix the Dispose 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.

• With an MVC controller, it makes the most sense to go ahead and use MVC's filters.
• For a middle-tier service that you would pull out of your IoC container, filters are not an option (because it's not a controller), so you should use the interception features of your IoC container.
• For your domain objects that you typically either instantiate directly with a constructor (if it's a new entity) or fetch from your ORM of choice (if it's an existing entity), you'll need to use some sort of object factory instead of the constructor and instruct your ORM how to use the factory.

The nitty gritty details about how to accomplish all of this will depend on which tools you are using.

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.