Where and how to use interceptors in a web application?

Question

I am interested in the concept of an interceptor recently. I know that this concept is used in many libraries, such as NHibernate, Entity Framework and others. But I'm interested in how to use this concept in an ASP.NET MVC web application.

Where is it useful to use it in an Mvc web application?

Is there any open source Asp.Net Mvc project that uses interceptors?

Asp.net Mvc already supports a kind of interceptor for the controller with filters. Is it better to use filters instead of interceptors?

Answer 1

Where / When to Use Interceptors

Take a look at the previous application you developed and study the code. Look for code that is often duplicated at the beginning or end of methods and properties. This is code that you can consider moving from all of these methods to an interceptor. For example, I noticed that many of my MVC actions doing input validation do this with the same pairs of lines of code:

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

This is code that could potentially be moved to an interceptor (perhaps in this case an MVC filter). Does the cost of writing and applying a filter increase the cost of this duplicate code? (2 lines of code multiply the number of controller actions using this). In this case, perhaps not. However, there are other situations where the advantage of using an interceptor will be greater.

Here is a list of some situations where I assume that this type of code duplication can occur, that is, scripts that smell like they could use sniffers :

• Input validation (as shown above).
• Debug Logs You can write an interceptor that records the input and output of each method call.
• Stream Sync. . Your question is about web applications, but if you are developing a Windows application with an MVP style representation, you can use an interceptor that ensures that all method calls are synchronized with the user interface thread.
• Database Operations. Most of my database transaction code is as follows:

 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 carefully studied how to automatically implement this event using various frameworks .
• Security. There are probably many methods in your application that should be limited to specific users only. AuthorizeAttribute is the filter for just that.
• Web service request throttling. Some APIs, such as the Basecamp API, ask you to limit your requests to a specific number of requests over a specific period of time. If you wrote the Basecamp client class, you can apply an interceptor to it to make sure that all method calls comply with the speed limit using Thread.Sleep when necessary.
• Caching Results. MVC has some filters pre-created for this purpose . You can write your own interceptor to cache results for layers below the user interface layer.
• WCF error handling. You cannot Dispose WCF client to the client if it is in the Faulted state, so every method that creates and destroys the client instance must check the state, then call Abort if necessary, and not just wrap the using clause around the client. In this case, the interceptor may not be the best. It might be easier to just fix the Dispose implementation or use some kind of wrapper .

Whether the above examples are good candidates for interceptors depends on the unique subtleties of your application. This list, of course, is not exhaustive, and cannot be. The possible applications of interceptors are as diverse as the applications you write.

How to use interceptors

I can think of three main places where you could use interceptor objects: Controllers, Services, and Domains.

• With an MVC controller , it makes sense to go ahead and use MVC filters .
• For the mid-range service that you pull from your IoC container, filters are not an option (because it is not a controller), so you should use the intercept functions of your IoC container .
• For your domain objects , which you usually either create directly using the constructor (if it is a new object), or choose from your ORM selection (if it is an existing object), you will need to use the factory object instead of the constructor and instruct your ORM how to use factory .

The detailed details on how to accomplish all this will depend on which tools you use.

Answer 2

Interception can be used for many things - most noticeable for solving cross-cutting issues such as instruments, logging, auditing, security, measurement, etc.

You do not 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 keep yourself in the MVC environment when you can apply a common implementation?

Answer 3

I would say that you use a more general DI container to inject your dependencies. It depends not only on these dependencies in your controller, but also on the dependencies of these dependencies, which leads to a complete graph of the objects of all your dependent objects.

Using a DI container for the front end also provides great opportunities to make your rear end narrower, testable and loosely coupled.