don't work on a Sunday. My boss doesn't work on a Sunday. Therefore, I don't see why my business objects should work on a Sunday either. Of course, there will always be someone trying to access my application on a Sunday, but it's easy to make use of the Policy Injection Application Block and a simple custom call handler to give objects, methods, and properties a well-earned day off.
OK, so maybe this isn't a fully "real-world" scenario, but it will give you useful guidance in how to make policy injection work for you. As part of Enterprise Library, the Policy Injection Application Block lets you control the behavior of your applications through configuration. The example handler, by default, blocks Sunday access to any individual target method or property. You can specify the methods or properties either through configuration or by using a custom attribute in code. The sample handler optionally allows you to block access on a Saturday as well. Your objects can then have a whole weekend to rest and recover from the previous week's exertion.
Figure 1 shows the new handler within the Enterprise Library Configuration Console. You can see that it has a property named NotSaturdayEither, which determines whether the handler will block invocation on Saturdays as well as Sundays.
|Figure 1. Sample Handler in Enterprise Library Configuration Console: The figure shows the process of adding the NeverOnASunday handler to an application's configuration.|
The Policy Injection Application Block, part of Enterprise Library 3.0 from Microsoft's patterns & practices group, provides powerful yet easy-to-use techniques for applying policies to objects within your applications. This article looks at how you can create custom handlers for the Policy Injection Application Block, and integrate them with the block so they function just like the built-in handlers.
The process of creating a new handler is simple, and you can easily create a new handler attribute for it so that developers can add the handler to methods and properties at design-time as well as through configuration. Creating the classes to integrate the handler with the configuration tools is a little more complex, but does improve the ease of use for administrators and developers. Therefore, the remainder of this article looks in detail at:
- How the Policy Injection Application Block uses call handlers
- How to implement the custom NeverOnASunday call handler
- How to integrate the custom handler with the configuration tools
- How to implement the NeverOnASunday call handler attribute
- How you can use the NeverOnASunday handler in ASP.NET applications
Policy Injection Application Block Call Handlers
|Author's Note: For more information about the Policy Injection Application Block, and its use in ASP.NET applications, see my earlier article "Using the Policy Injection Application Block in ASP.NET." For technical details about how the block works, see the topic "Design of the Policy Injection Application Block" in the Enterprise Library Help file. For more details about Enterprise Library, see http://www.codeplex.com/entlib/.
The Policy Injection Application Block (PIAB) implements a pipeline of call handlers based on attributes that decorate members of target objects, and on sets of Matching Rules defined within the application configuration. The combination of all these is a Policy. When code uses the static Create
methods of the PolicyInjection factory class, the block discovers which handlers to apply, builds the pipeline, and injects it between the calling code and the target object.
When the client code calls the target object member (method or property), the block intercepts the call and passes it through all of the configured handlers in the order they are defined in the configuration. Each handler can execute code when called from the client or a previous handler in the pipeline (the pre-processing stage), before invoking the next handler. Handlers can also execute code when the following handler returns control to this handler, after the target method or property access completes (the post-processing stage).
Most handlers perform their tasks in the pre-processing stage, although several built-in handlers use both stages. For example, the Caching Handler looks for a cached result in the pre-processing stage and short-circuits processing to return this value if found; otherwise, it uses the post-processing stage to save the returned value into the cache ready for the next call.
Handlers can, if required, abort the process and short-circuit the call to the target object member. In this case, the handler should generate a suitable return message (perhaps containing an appropriate exception), and pass this back to the previous handleror to the client if this is the first handler in the pipeline.