0

I will start by specifying that I am new to Interception.

I want to replace some existing implementation of my project by bringing Interception into play, but I noticed that it actually brings me to be very tightly coupled to the AOP framework behind (either Castle.DynamicProxy, Unity.Interception, LinFu.AOP, same story). What if I have to switch between them? (there are plenty of reasons why).

So, whenever I have to create different interceptors, these interceptors must comply specific AOP framework. There is always a need to carry the AOP framework specific invocation information (and thus to reference the AOP assemblies)

Simple example showing a "before" interceptor with Castle DynamicProxy:

public abstract class BeforeInterceptor : IInterceptor 
{
     void IInterceptor.Intercept(IInvocation invocation) 
     {
       Before(invocation);
       invocation.Proceed();
     }

     protected abstract void Before(IInvocation invocation);
}

As I understood, IInvocation must be carried into the interceptor implementation, for better control when method is invoked on the target.

What are your suggestions and recommendations. Maybe I am seeing this from a wrong angle.

PS: When using such libraries for DI, it is not the case, there is no such tight coupling.

Learner
  • 3,297
  • 4
  • 37
  • 62
  • 1
    If it's just one or two classes then the simplest thing to do would be to hand-roll your own Decorators. If you have more than that, you could generate the decorators using Roslyn / Code gen, perhaps with T4 templates and / or custom actions in your build. If you need consuming code to not 'know' about the decorator type then custom Type Descriptors may help. – Toby Couchman Mar 03 '16 at 11:35
  • Thanks for your recommendations Toby! – Learner Mar 03 '16 at 12:47

1 Answers1

0

Having your interceptors coupled to a DI implementation isn't so bad. The reason that code is in the interceptor is because it doesn't belong in the class whose method is being intercepted. It's usually some behavior that you don't want coupled to your class, and it's outside the responsibility of that class. So if you're coupling your interceptors instead of your "main" classes then it's a decent trade-off. It's keeping those classes uncoupled.

Also, the setup of your DI container doesn't have to be in the same project as the related classes. If you wanted to you could have a Windsor installer to wire up your classes and interceptors for Windsor and another for unity. That's duplication, but the fact that you can have both means you aren't technically coupled to either.

And the code in your interceptors is usually pretty minimal. If it's doing anything too complicated then perhaps it doesn't belong there.

Scott Hannen
  • 27,588
  • 3
  • 45
  • 62
  • You said interceptor's code should be minimal, in general... Actually I thought I could use interceptors when having some extra checks to add in certain conditions on only couple of BL methods inside one BL object (eg. license based, etc) ... I don't want to create interceptors at BL level which are tight to any AOP/DI framework – Learner Mar 10 '16 at 10:07
  • My concern is becoming too dependent on a DI implementation. I'd hesitate to put business logic in an interceptor. I use them for concerns that aren't related to that logic (and so doesn't belong in those classes.) In some cases I'm probably already coupled to Windsor and need to revisit some details. – Scott Hannen Mar 11 '16 at 12:52