Understanding the Policy Injection Block

Use the Policy Injection Block to Manage Cross-cutting Concerns in Your Applications

asp:Feature

LANGUAGES: C#

ASP.NET VERSIONS: 2.0

 

Understanding the Policy Injection Block

Use the Policy Injection Block to Manage Cross-cutting Concerns in Your Applications

 

By Joydip Kanjilal

 

The Policy Injection Block from Microsoft is great for separation of concerns. The Policy Injection Block is a part of the February 2007 CTP of the Microsoft Enterprise Library and can be used to provide Aspect Oriented Programming (AOP) features in your applications. You can use it to isolate the core concerns from the cross-cutting concerns of your application. This article presents the features of this block and their applicability.

 

Using the Policy Injection Block

According to MSDN:

 

Applications include a mix of business logic and crosscutting concerns, and the two are typically intermingled which can make the code harder to read and maintain. Each task or feature of an application is referred to as a concern. Concerns that implement the features of an object within the application, such as the business logic, are core concerns. Crosscutting concerns are the necessary tasks, features, or processes that are common across different objects for example, logging, authorization, validation, and instrumentation. The purpose of the Policy Injection Application Block is to separate the core concerns and crosscutting concerns.

 

To use the Policy Injection Block, you must add references to the assembly files listed here:

  • Microsoft.Practices.ObjectBuilder
  • Microsoft.Practices.EnterpriseLibrary.Common
  • Microsoft.Practices.EnterpriseLibrary.PolicyInjection
  • Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers

 

Then, in your program, you must include the following namespaces:

  • Microsoft.Practices.EnterpriseLibrary.PolicyInjection
  • Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers

 

To store the policy information, you must use configuration in your config file similar to that shown here:

 

<policyInjection>

   <policies>

       <add name="firstPolicy">

           <matchingRules>

                <add name="firstRule" ... />

               <add name="secondRule" ... />

           </matchingRules>

           <handlers>

               <add name="firstHandler" ... />

               <add name="secondHandler" ... />

           </handlers>

        </add>

       <add name="secondPolicy">

           <matchingRules>

               <add name="firstRule" ... />

               <add name="secondRule" ... />

           </matchingRules>

           <handlers>

               <add name="firstHandler" ... />

               <add name="secondHandler" ... />

           </handlers>

       </add>

   </policies>

</policyInjection>

 

Fine, but, how do you achieve the AOP functionality we talked about earlier? You can achieve AOP functionality by intercepting the method calls in your program and executing the handlers that are defined in the configuration file (as shown in the code snippet above).

The AOP functionality is achieved by intercepting the method calls in your program, then executing the handlers that are pre-defined in the configuration file (see the example code snippet shown earlier). The handlers are executed both before and after the method calls. The handlers are used to specify what action needs to be performed once a method call is intercepted. The method calls are actually intercepted based on the defined rules in the configuration file. If these rules match, the method is intercepted and executed is the respective handler as defined in the configuration file for that rule that has matched.

 

A policy is actually a combination of the pipeline of the handlers and the set of the matching rules that are defined in the configuration file of an application that uses the Policy Injection Block. Once the static Create method that belongs to the factory class named PolicyInjection is executed, a method call is intercepted by the block, the handlers to be executed are identified and injected before and after those method calls. You can even use your own custom handlers to apply your custom policies.

 

For more information on the Policy Injection Block, look at the MSDN article Policy Injection Application Block at http://msdn2.microsoft.com/en-us/library/bb410104.aspx.

 

Conclusion

This article has explored the Policy Injection Block from Microsoft and how it is beneficial for separation of concerns. Please send me your comments. Happy reading!

 

Working extensively in Microsoft technologies for more than 10 years, Joydip Kanjilal is a Microsoft MVP in ASP.NET and a Senior Technical Leader in the Design and Architecture team for a reputed company in Hyderabad, India. He has more than 12 years of industry experience in IT. His programming skills include C, C++, Java, C#, VB, .NET, AJAX, VC++, ASP.NET, XML, UML and Design patterns. He has worked with .NET and C# for more than five years. Reach Joydip at mailto:[email protected] or at his blog at http://aspadvice.com/blogs/joydip/. He also is the author of ASP.NET Data Presentation Controls Essentials (http://www.packtpub.com/author_view_profile/id/176). His hobbies include watching cricket and soccer and playing chess.

 

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish