Microsoft’s .NET Enterprise Library 3.0 Brings AOP (or AOSD if you prefer) to the masses in the form of the Policy Injection Application Block (PIAB), another code factory implementation that allows code to be “advised” by policies which can be configured after compilation.
Released last week, Enterprise Library 3.0 includes a metric ton of features in it’s various “Application Blocks” for Caching, Cryptography, Data Access, Exception Handling, Logging, Policy Injection, Security, and Validation. There are several good blog posts on the new Policy Injection stuff from the Patterns and Practices developers and C# MVPs, so since I’m still discovering this stuff, I’ll just link you to a few of them with some comments.
Announcing the Policy Injection Application Block
The Policy Injection Application Block will simplify the separation of business logic from cross cutting concerns, by letting you define policies and the objects/methods they apply to in a declarative way.
You be the judge. If that’s not a great description of Aspect Oriented Programming methods, then I must have wasted my time in school
Policy Injection App Block – Behind the Scenes Annotated
This is a very good read for anyone interested in how the PIAB works or in what Aspect Oriented programming is really all about, it’s particularly interesting if you have a grasp of some of the many ways that current AOP toolkits work, because he explains their evaluation of various weaving methods and why they chose the one they did.
We use an interception mechanism to get in the way of calls going to that member, collect a list of policies that apply using a matching rules mechanism, run the chain of handlers specified by those policies in a chain of responsibility and at the other end dispatch the call to the target. Once the target is done – successfully or with exceptions – the stack unwinds, returning through each handler and finally back to the caller.
The sad thing is that it seems to be mostly a business decision, and does not yield the most powerful implementation, nor the easiest to work with. Only objects created through their Policy Injection factory can be advised, but at least it sounds like they offer “around” advice (which would inherently allow before and after). At any rate, you get the ability to separate cross-cutting concerns and even create and apply policies and even business rules after the fact. The decision does have one important upside: not only is the code produced by this supportable by Microsoft Product Support, it’s now officially part of the Patterns and Practices recommendations!
Policy Injection Application Block Validation and Logging Examples
David Hayden is a Microsoft MVP for C# and a web developer … he’s written a lot of tutorials (including one over here about Windsor AOP which discusses a few of the AOP features which are sadly, not in the PIAB) and gives some explanation of how the Policy Injection Application Block in Enterprise Library 3.0 really is Aspect Oriented Programming … there’s a good screenshot there of the various “matching rules” ...
Honestly, it’s kind of a shame that Microsoft couldn’t bring themselves to use AOP terminology to describe this functionality: weaving instead of “injection”, advice instead of “handlers”, pointcuts instead of “rules” ... etc. It would really have made it easier to follow for people already familiar with AOP, and would have lent some credibility both to the PIAB and to AOP research and development in general.
Similar Posts:
- None Found