Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Using the Policy Injection Application Block in ASP.NET

Learn how to use AOP injection techniques to add, remove, and modify logging, validation, caching, exception handling, authorization, and performance measurements in your ASP.NET applications—without having to recompile your code.


advertisement
ne technique becoming increasingly popular with developers is the adoption of an Aspect-Oriented Programming (AOP) model. AOP provides techniques for changing the behavior of business objects and other classes through the application of policies, making it easier to implement common crosscutting concerns such as logging, validation, exception handling, caching, and more. The terminology of AOP uses the word "concern" to mean a task or feature of an application. Core concerns are the features usually unique to a class or object, such as extracting specific data from a database, or calculating the result of a function directly applicable to the class or object. Tasks common to more than one class or object are crosscutting concerns. Poor management of these can result in duplicated and hard-to-manage code, and unreliable applications.

Policy injection provides one approach to simplifying and unifying the implementation of crosscutting concerns. This is a feature introduced by the Microsoft patterns & practices (p&p) group into the latest release (version 3.0) of Enterprise Library. This new Enterprise Library version contains the Policy Injection Application Block, which integrates with the other application blocks in the library to support simple management across applications and business objects of features such as logging, exception handling, caching, validation, authorization, and instrumentation. About the Policy Injection Application Block
The Policy Injection Application Block supports the application of policies for managing crosscutting concerns through an interception method that creates a handler pipeline and injects handlers into that pipeline. As the application makes calls to methods and properties of the target object, the handler pipeline executes each handler in turn—both on the way to the target object (the pre-processing stage) and on the way back (the post-processing stage). Each handler can perform tasks that carry out a required feature, such as logging or validation.

The Policy Injection Application Block is highly flexible and extensible. A set of built-in handlers provided with the block perform the common tasks exposed by the other application blocks within Enterprise Library. Developers can write custom handlers to accomplish almost any other tasks their applications require. They can even integrate these custom handlers with the Enterprise Library configuration system, making it simple to add policy-based configuration—in exactly the same way as the built-in handlers. Developers, administrators, and operators can create handler pipelines in two ways. For developers, the direct route is to decorate classes and/or class members with the attributes exposed by the Policy Injection Application Block. For example, adding the [ValidationCallHandler] attribute to a class member specifies that the block should validate the parameters in line with specific validation attributes applied to each parameter.



For enterprise solutions, an alternative approach is the use of a configuration file or other configuration resource. Enterprise Library supports a range of configuration options, such as application configuration files (App.config and Web.config), custom configuration files, and configuration stored in a database. Developers, administrators, and operators can configure policies (including the addition of new policies) simply by editing the application configuration. This approach provides an excellent technique for managing applications post-deployment, and lets administrators change application behavior to meet changing conditions and requirements without requiring recompilation. In conjunction with the new Group Policy-driven configuration management features in Enterprise Library 3.0, this allows central administration of all computers in an Active Directory domain or forest that run the application. Some common uses for the Policy Injection Application Block with the default set of handlers are:

  • Logging method calls and access to properties of the target object, and providing information about the context of the call and any parameter values provided.
  • Validating the values of parameters for methods and property Set accessors.
  • Caching the return value from methods and property Get accessors.
  • Handling exceptions in a structured way; for example, by wrapping or replacing them with other specific exception types.
  • Authorizing requests to target objects based on the current thread identity.
  • Measuring target object method and property execution times and exception generation rates by adding performance counters.
Many features of the Policy Injection Application Block make it easy to modify the block completely if the default implementation does not suit your requirements. For example, you can reuse the matching rules, handlers, policies, and other core types with your own interception mechanism if you create a custom proxy and injection pipeline generator.
Author's Note: For more details of Enterprise Library, and to download the latest version, see http://www.codeplex.com/entlib.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap