RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Using the Policy Injection Application Block in ASP.NET : Page 6

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.

Behavior of the Logging Handlers
The example application applies the Logging Handler in two circumstances:

  • To the InterfaceCustomerModel's GetCustomerNameWithWildcard and GetCustomerList methods, the application apples the Logging Handler through the InterfaceModelPolicy declared in the configuration. This policy generates messages in the audit.log file and in the Windows Event Log.
  • To methods with any name that take a single parameter of type System.String, the application apples the Logging Handler through the AttributeModelPolicy declared in the configuration. This policy also uses a Namespace Matching Rule, and so it selects only the GetCustomerName and GetCustomerDetails methods of the AttributedCustomerModel class. This policy generates only audit.log file messages.
Executing one of the methods listed above should produce log messages in the relevant logs. For example, executing GetCustomerNameWithWildcard with the value "A" for the single parameter produces both a "Before" and "After" entry in the audit.log file. Here's the content of the "After" message in the log file:
   Timestamp: 21/03/2007 10:50:01
   Message: After
   Category: AuditFile, EventLog
   Type: InterfaceCustomerModel
   Method: GetCustomerNameWithWildcard
   Parameters: customerID : A
   Return Value: Alfreds Futterkiste
   Call Time: 00:00:00.0002551
   Priority: 0
   EventId: 0
   Severity: Information
   Title: Call Logging
   Application Domain: f4e1bb0-9-128189471987530168
   Process Id: 3724
   Process Name: WebDev.WebServer.EXE
   Win32 Thread Id: 2412
   Thread Name:
Figure 6. Event Log Entries: Here's a Logging Handler entry in the Windows Event Log.
You can see that the audit.log file message contains a wealth of information, including the target type name, method name, parameters, return value, call duration (Call Time), and more. You can configure for more or less information using the Logging Handler settings, or in the Logging Application Block section.

The call to the GetCustomerNameWithWildcard method also generates "Before" and "After" entries in Windows Event Log, containing the same information as the audit.log file entry. Figure 6 shows the same "After" message generated by the Logging Block in Windows Event Log.

You can execute the other methods to which this handler applies, and view the results in the audit.log file and (for the InterfaceCustomerModel.GetCustomerNameWithWildcard and the InterfaceCustomerModel.GetCustomerList methods) in the Windows Event Log. However, you will discover that the AttributedCustomerModel.GetCustomerName method does not generate any log file entries, even though the matching rules for the AttributeModelPolicy declared in the configuration select this method. This is because, as you saw earlier, this method carries the ApplyNoPolicies attribute:

   public String GetCustomerName(String customerID)
The ApplyNoPolicies attribute overrides the configuration, and prevents the block from applying the configured policy to this member.

Behavior of the Validation Handlers
The example application applies the Validation Handler in only one circumstance—for the AttributedCustomerModel.GetCustomerDetails method through a directly applied attribute:

   public DataRow[] GetCustomerDetails([StringLengthValidator(
      5, RangeBoundaryType.Inclusive, 
      5, RangeBoundaryType.Inclusive)] 
      String customerID)
If you execute this method with a customer ID consisting of anything other than five characters, you will see the error raised by the Validation Application Block:

   <span class="pf">ERROR: Parameter validation failed Parameter name: customerID
There are many ways that you can set up validation using the Validation Application Block, in particular by creating Rule Sets that can customize the validation error message. There is also a huge range of validation types you can take advantage of in your application configuration, or as validation attributes on parameters.

Author's Note: If you decide to experiment with the example by validating methods of the InterfaceCustomerModel class (such as GetCityList) using attributes, you must apply the [ValidationCallHandler] attribute to the method declaration in the concrete InterfaceCustomerModel class, but apply the validation attributes such as a [RangeValidator] to the declaration of the method in the ICustomerInterface. This is required because, as you saw earlier, the Policy Injection Application Block cannot see the original class through the proxy it creates.

In this article you have seen one of the latest additions to Enterprise Library—and its use within a simple ASP.NET example application. Microsoft's patterns & practices group added a raft of new and updated features to version 3.0 of Enterprise Library, including the Policy Injection Application Block described here—a new block that provides a flexible, configurable, and extensible solution for managing crosscutting concerns in enterprise-level applications.

The Policy Injection Application Block allows developers, administrators, and operators to change the behavior of business objects and target classes by injecting a pipeline containing handlers between the client application code and members of the target class. These handlers can help to minimize crosscutting concerns by implementing tasks such as validation, caching, logging, and authorization with no extra effort required by developers or administrators. Instead, the handlers integrate with the other application blocks within Enterprise Library and take advantage of the features they expose.

Developers can hard-code policies into objects using attributes, and administrators can add, remove, or modify policies using the configuration tools. In conjunction with new Group Policy configuration management capabilities within Enterprise Library, The Policy Injection Application Block provides a simple to use, yet enterprise-wide and powerful technique for managing ancillary tasks and crosscutting concerns.

In addition, developers can extend the Policy Injection Application Block by creating new handlers, handler attributes, and matching rules. They can even modify the block to change the interception and pipeline injection mechanism to suit their specific requirements.

Alex Homer is a director of Stonebroom, Ltd., a software development, consulting, and training organization. He was formerly lead technical author and reviewer for Wrox, specializing in Microsoft Web and database technologies. You can reach him through his Web site.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date