Effective Policy Viewer for the Policy Injection Application Block

I hope you're enjoying the new release of Enterprise Library! One of the more interesting inclusions in this release is the new Policy Injection Application Block. The goal of the PIAB is to make it easier to separate cross-cutting concerns from business logic, using declarative policies. A policy consists of a set of matching rules, which indicate which objects and methods the policy applies to, and a chain of handlers, which are objects that execute before and/or after a method is called to accomplish interesting stuff. The PIAB ships with 6 handler types that provide implementations for logging, validation, exception handling, authorization, caching and performance counters.

Using the PIAB intelligently in your application should allow you to write simpler, more maintainable code. However a few people have already pointed out that this separation of business logic from cross-cutting concerns has the potential to cause confusion, since it won't be possible to understand the complete behavior of the application by looking only at the code. While this problem can be mitigated by applying handlers directly using handler attributes or indirectly via the TagAttribute, I do agree that this style of development does carry a different set of risks to more traditional development styles.

To help take the mystery out of which policies will apply to which objects and methods, I put together a simple tool called the Effective Policy Viewer. This tool is not included in the Enterprise Library 3.0 installer; instead I've uploaded it directly to the EntLib CodePlex site, so we can more easily update it over time. Here's the tool looks like:

The tool lets you load an assembly, and optionally a configuration file (if you don't select a configuration file it will only look for handlers applied using attributes). The left-hand tree view control will show all of the namespaces, classes and members in the assembly. If a class appears greyed-out, it means that none of the members have policies applied to them. If the class is black, you can expand it to see which members have policies applied to them. Selecting a member will show the list of policies and handlers in the right-hand tree view control. The order that the handlers are listed in the control reflects the order that they will execute at runtime. Keep in mind, however, that policies will only run when objects are created or wrapped using the PolicyInjection class, but this tool can't verify that you're doing this.

Please let us know if you have any feedback or problems with this tool. This was built in my spare time so it hasn't gone through any real review or tests, but if there are problems then it shouldn't take long to update it. If anyone feels like "supercharging" the tool and sharing your changes, please go right ahead!

Comments

• Anonymous
  April 06, 2007
  The comment has been removed

• Anonymous
  April 07, 2007
  The comment has been removed

• Anonymous
  April 08, 2007
  Tom, What if there was an "order" parameter for the handlers? [ValidationCallHandler(0)] [CacheHandler(1)] public IList GetSomeData() { } In this case validation handler would run before cache handler because the order parameter defined that. No matter wich order the reflexion API would return them. Actually I suggested it few posts ago. I think this is a very important feature, because I believe that in most of the cases the handlers to be applied are known in compile time and should not be changed in runtime. Daniel

• Anonymous
  April 08, 2007
  Thanks Daniel - agree this is a good idea given the way the .NET reflection APIs behave. Unfortunately we didn't have time to add any new features in the release at the time you originally suggested it, but it looks like a great thing to add in the future. Tom

• Anonymous
  April 09, 2007
  Enterprise Library 3.0patterns & practices Developer Center The patterns & practices Enterprise...

• Anonymous
  April 12, 2007
  There is "Constructor not found" exception when running programs using my own custom call handler for policy injection application block. The Constuctor cannot be found due to the use of NameValueCollection at the 2nd argument castedObjectConfiguration.Attributes of Activator.CreateInstance() inside CustomerProviderAssembler.cs public TObject Assemble(IBuilderContext context, TConfiguration objectConfiguration, IConfigurationSource configurationSource, ConfigurationReflectionCache reflectionCache) { TConcreteConfiguration castedObjectConfiguration = (TConcreteConfiguration)objectConfiguration; TObject provider = (TObject)Activator.CreateInstance(objectConfiguration.Type, castedObjectConfiguration.Attributes); return provider; }

• Anonymous
  April 13, 2007
  Beramode, If you are using the CustomCallHandlerData to configure your own handler, you'll need to add a constructor to the handler that takes a NameValueCollection as a parameter. That's just the way it works. This should be documented better. The other option would be to create a configuration data class and assembler for your custom call handler. This has the advantage of showing exactly what your configuration options are in the config tool.

• Anonymous
  April 18, 2007
  Hi Tom, Sorry this question isn't related to your blog entry. I have a couple of custom exception handlers, I can edit my config and add my handlers no problems with the EntLibConfig.exe tool. However when I attempt to use editor integrated into Visual Studio it doesn't seem to know about my custom exception handlers.  Any hints on how you can get this to work?

• Anonymous
  April 28, 2007
  Better late than never... I have combined the last 3 weeks. In the pipeline: So much is in the pipeline