Policy Injection Application Block

Here's something we all have been waiting for ages: the Policy Injection Application Block.

Here's Hollander's definition:

But first things first: what the hell is this thing? The short(ish) answer is that 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. Each policy contains a pipeline of "handlers" that are executed before and after a policy-enabled method is called. The handlers can do whatever you want, but the most common scenario will be to implement cross-cutting concerns such as logging, validation, exception handling and authorization. By amazing coincidence, Enterprise Library already includes blocks that implement these kinds of capabilities, so our out-of-the-box handlers will be simple wrappers over existing application blocks.

I see it as a very focused Aspect Oriented Programming. Let me show you why:

While the number of handlers and the details on how they will work are not
entirely set in concrete, here is what we are hoping to include:

• Validation Handler. This will look for validation rules applied on the method parameters or within types in the message signature, and call the Validation Application Block to check the supplied parameters against the validation rules. If validation succeeds the method will be called. If not, the handler chain will be aborted and an exception will be returned to the client.
• Logging Handler. This will call the Logging Application Block to write a log message either before the method is called, after the method is called, or both. Optionally the handler will be able to log details such as supplied parameter values and call execution time.
• Exception Handling Handler. This handler will do nothing before the method is called, and do nothing after the method is called unless an exception was thrown. If an exception was thrown, the handler will pass it to the Exception Handling Application Block using a specified exception policy, and any resulting exceptions will be returned to the client. In effect this will eliminate the need for boilerplate exception blocks when using the Exception Handling Application Block.
• Performance Counter Handler. This will create a number of performance counter instances measuring things like number of calls, calls per second, average call execution time and number and rate of exceptions thrown by the target method.
• Authorization Handler. This handler will use a specified authorization provider configured with the Security Application Block to check if the current user (obtained from the thread principal) is authorized to perform the current task (specified in the handler configuration). If so, the target object is called. If not, an exception will be returned to the client.
• Caching Handler. This handler will generate a cache key based on the target
  method signature and values, and use the Caching Application Block to see if the method has already been called with these values within the configured cache threshold. If a value was found in the cache, it will be returned to the client and the handler chain will be aborted (i.e. the object will not actually be
  called). If a value was not found in the cache, the method will be called, and
  the return value will be added to the cache on the return path.
  

Looking forward to play with these... We can now finally enrich the latest Active Record implementation of our choice with the authorization and logging funcionalities we always have. And we won't have to rewrite the code that generated those :)