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
Category: AuditFile, EventLog
Parameters: customerID : A
Return Value: Alfreds Futterkiste
Call Time: 00:00:00.0002551
Title: Call Logging
Application Domain: f4e1bb0-9-128189471987530168
Process Id: 3724
Process Name: WebDev.WebServer.EXE
Win32 Thread Id: 2412
|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
public String GetCustomerName(String customerID)
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 circumstancefor the AttributedCustomerModel.GetCustomerDetails
method through a directly applied attribute:
public DataRow GetCustomerDetails([StringLengthValidator(
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 Libraryand 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 herea 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.