Aspect Oriented Programing and Policy Injection Application Block (Part - 2)

As mentioned in Part 1 of this article series, The Policy Injection Application Block is used to seperate the core concerns of the entity by using handlers available in the block. You can also create your own custom handlers by implementing the ICallHandler interface.

PIAB can be used to specify crosscutting behavior of objects in terms of a set of policies. A policy is the combination of a series of handlers that execute when client code calls methods of the class and—with the exception of attribute-based policies—a series of matching rules that select the classes and class members (methods and properties) to which the application block attaches the handlers.

A handler can be defined either

• By decorating class members with an attribute that will declaratively define the handler to be used

OR

• By defining the class type and class member on which the handler will act

A common scenario when using any policy injection framework is the requirement to specify policies for classes and their members using attributes directly applied to the appropriate classes and members. The PIAB supports this technique; this means the only configuration required is the addition of the application block to the Enterprise Library configuration for the application. After that, the application block actively discovers classes and members with the attributes defined within the Policy Injection Application Block applied, and then the application block applies the appropriate policies.

Some of the common scenario where PIAB can be used in your application includes

• Logging Method Invocation and Property Access
• Handling Exceptions in a Structured Manner
• Validating Parameter Values
• Caching Method Results and Property Values
• Authorizing Method and Property Requests
• Measuring Target Method Performance

In the below given example I have used PIAB to handle exceptions, Caching and Validation purposes.

public class User : IUser

{

#region IUser Members

[ExceptionCallHandler("My Exception Policy")]

[CachingCallHandler]

public Collection<Int32> GetUserIDs()

{

return GetUserIDsFromDB();

}

private Collection<Int32> GetUserIDsFromDB()

{

Collection<Int32> ids = new Collection<Int32>();

ids.Add(1);

ids.Add(2);

System.Windows.Forms.MessageBox.Show("Getting ID's from DB");

return ids;

}

[ExceptionCallHandler("My Exception Policy")]

[ValidationCallHandler]

public void UpdateAge([RangeValidator(typeof(Int32), "20", RangeBoundaryType.Inclusive, "100", RangeBoundaryType.Exclusive)] Int32 age, Int32 index)

{

//Implementation code goes here

}

#endregion

}

After having the entity created with the appropriate handlers for avoiding cross concerns you can use the PIAB factory class methods for creating or obtaining object instances:

• Create: This method creates a new instance of a policy-enabled interceptable target object.
• Wrap: This method adds policies to existing interceptable target object instances.

IUser user = PolicyInjection.Create<User, IUser>();

And call the interface methods like

Collection<Int32> usersids = user.GetUserIDs();

The implementation of a system that automatically creates a proxy and handler pipelines for methods is similar to the aspect-oriented programming (AOP) approach. However, the Policy Injection Application Block is not an AOP framework implementation for the following reasons:
• It uses interception to enable only pre-processing handlers and post-processing handlers.
• It does not insert code into methods.
• It does not provide interception for class constructors.