Policy Injection App Block of EntLib 3.0 - An implementation of AOP

Details have finally emerged about Policy Injection App Block (PIAB) in the upcoming EntLib 3.0 - see here and here. I have been curious and wanting to see this as this is a form of Aspect-Oriented Programming (AOP). I have worked quite a bit on my company's framework, which has a different variation of AOP. What I like about PIAB from p&p is that it doesn't impose restriction of AOP at physical boundaries, as opposed to, say, binding AOP to the service boundary. The arguments for binding AOP to only the service boundary are basically concerning about the undisciplined use of AOP, thus causing aspect "meatballs" throughout the application. I think the decoupling of AOP from physical application boundaries bring more benefits and goodness to the application architecture. Remember that we could configure attributes, such as transaction, security for components in MTS and later COM+. If a framework makes the aspect feature highly configurable, I wouldn't agree to the "meatballs" argument. Besides, any language or framework in existence today, while making developers lives easier, still can't be savior of all problems without disciplines from developers - This is where good development process comes in. So I think most of the developers would appreciate the freedom that PIAB offers.

The PIAB implementation, though, seems to be somewhat controversial. Instead of a few sound alternatives, they picked remoting. p&p didn't want to mess around the runtime by using CLR profiler APIs or JIT Debugger callbacks to rewrite IL at runtime. However, the reason for not using IL rewriting, should not be they are obscure or not supported by PSS. Instead, The CLR already has ContextBoundObject, which is designed for this very purpose of interception. Don Box's Essential .NET book has a good coverage of this topic in chapter 7. As a matter of fact, I have seen a lot of AOP implementations using ContextBoundObject in the field. So I really don't understand the argument "not recommended for customer code" in Edjez's blog. Maybe the CLR team can shed some light on this. Honestly I don't see why remoting is a better choice and wouldn't be replaced in future releases of EntLib. We know that remoting was not designed to BE an interception mechanism, although with an interception mechanism.

Although not stated by the blogs, I suspect that the lack of "new" interception in the object builder framework may have been a driver to using remoting instead of ContextBoundObject. But based on my experience so far, besides being internally used by the other blocks, object builder hasn't got wide adoption, due to lack of documentation and API complexities. An important success factor for a framework, no matter how good the framework is, is the ease of use of its APIs. I am waiting to get my hands on the February CTP of EntLin 3.0 to see how easy the PIAB can be used in conjunction with object builder. I am hoping that tying PIAB to object builder doesn’t make it more cumbersome to use as opposed to intercepting “new” with ContextBoundObject and making it completely transparent for the client code.