Enterprise Library 4.0 - Excited About Dependency Injection Application Block with PIAB
by David Hayden, Sarasota Web Developer
Grigori reminded me that the most exiciting thing about the new Dependency Injection Application Block in Enterprise Library 4.0 is the one-two-punch it delivers with the Policy Injection Application Block! I specifically talked about this powerful combination with Castle Windsor and remarked how awesome it would be if we had the same functionality in Enterprise Library:
Castle Windsor AOP - Dependency Injection and Aspect-Oriented Programming - Policy Injection Application Block
If you look at other frameworks, like Castle and Spring, the AOP Functionality is logically offered via the Dependency Injection ( DI ) / Inversion of Control (IoC) container, because it is the container that serves up objects and can seemlessly provide a proxy that intercepts method calls, etc.
The only thing we may need to provide a knock out punch is a lighter-weight interception mechanism in addition to the existing interception mechanism ( Remoting Proxies ). I say “may need,“ because I hear a lot about the heaviness and performance hit of Remoting Proxies, but don't have a lot of knowledge on the subject myself.
Ed had a great post about why they picked Remoting Proxies and alternatives:
“...Here are some of the alternatives we evaluated.
Remoting proxies : Using Real/TransparentProxy
- Requires construction with a special factory
- Requires class to derive from MBRO, or to have an explicit interface.
- Proxy is treated as the real type by the type system (.NET special cases type identity checks around these objects)
Context Bound Objects : Using ContextBoundObject and attributes
- Allows interception of ‘new’
- Not recommended for customer code - therefore p&p won't ship it as part of guidance!
Assembly rewriting : Taking the IL of your assembly and injecting more IL into your classes
- Eliminates the need for proxy classes
- Completely compatible with the type system and ‘new’
- Can’t be used for external strong-named assemblies without delay-signing (pros and cons)
- Not supportable by Microsoft Product Support (PSS) as of today--> ouch
Generating derived classes : Taking your classes and generating wrapping classes that derive from them
- Requires construction with a special factory
- Only works for virtual methods on non-sealed classes
- Could result in type system issues
Generating inline interception code : Taking your classes and adding C#/VB code 'around' method bodies
- Requires code to be written in a special way
- Interception code is explicit, rather than “magic” (which has pros and cons)
- Requires source code for intercepted objects
Other more obscure mechanisms we discarded : Things that work but we wouldn't like to ship and you wouldn't like to maintain
- Using CLR profiler APIs
- Using CLR JIT Debugger callbacks for runtime IL rewriting...“
Comparing that list to Oren's list of 7 Approaches for AOP in .NET, I would love to get another interception mechanism, perhaps similar to the Rhino Proxy or Castle Dynamic Proxy, if it would offer a more performant and lighterweight alternative to Remoting Proxies.
Once we have a Dependency Injection Application Block in Enterprise Library 4.0 people will be more likely to use the Policy Injection Application Block and commenting on how the combination compares to Castle and Spring in terms of performance and functionality. Seems like Enterprise Library 4.0 would be a good time to add another interception mechanism to the PIAB.