Click here to Skip to main content
13,894,216 members
Click here to Skip to main content
Add your own
alternative version


23 bookmarked
Posted 19 Oct 2008
Licenced CPOL

Plug and play architecture using policy application blocks

, 19 Mar 2009
Rate this:
Please Sign up or sign in to vote.
This article explains plug and play architecture using policy application blocks.

Table of Contents


In this section, we will discuss how we can implement plug and play architecture using Policy Application Blocks. What we will do is, we will take a practical scenario where we want to enable logging for an application depending on situations.

For the past several days, I have been writing and recording videos for architects and project managers. You can watch the videos here.

Other Application Blocks

  • Validation application blocks: This article explains the 16 steps you need to perform to do validations using VAB: Validation application blocks.
  • Client side validation: One of the shortcomings in VAB is that it does only server side validations. This article talks about how we can leverage VAB for the client side: Client side validation.
  • Dynamic validation: This article explains how to build dynamic validation on a scenario basis: Dynamic validation.
  • Logging application block: This article explains the five basic steps to use Logging Application Blocks: Logging application block.
  • Data application: This article talks about the four steps you need to implement Data Application Blocks: Data application block.
  • Exception application block: This article explains how we can use exception application blocks to log exceptions from a project: Exception application block.
  • Unity application block: This article talks about the Unity Application Block in DI and IOC: Unity application block.
  • UIP block: This article talks about Reusable Navigation and Workflow for both Windows and Web using Microsoft UIP blocks: UIP block.


To understand the real use of policy application blocks, we will take up a real scenario. No application is perfect and it is very much possible that you can have defects in production. In production, as a rule, we have fully compiled DLLs and it will be very difficult to track down errors. We can definitely use TRACE to get to the bottom of the problems. One of the issues with TRACE is that we do not get verbose information. From Trace, we will just get to know which method has the issues.

Below is a solution which I am sure there are better ways of doing it. The whole point of this article is to understand how we can use the plug and play mechanism given by policy application blocks.

We will try to implement a plug and play mechanism. The application interface of our project calls business classes. When we want to enable debug mode, we will just plug in the logging application block. The logging application block will start logging in method calls in the event log which we can use to analyze issues we have in the application. In normal production mode, we will remove the logging feature. The below figure visualizes the same as a switch which can plug in the logging or plug it out.


To implement the above solution, we will use policy application blocks. Policy application blocks help us to plug in policies which can be added and removed on the fly. Using the enterprise application UI, you can add new policies or remove policies.


In order that the class methods can be monitored by the policy block, we need to inherit the class from an interface. For the current example, we want to monitor methods of the class clsFireMethods. You can see that we have inherited it from an interface IMethods.

Now open the web.config file of the project and add the policy injection block. When you add the policies, you will see two important nodes: one of the policy and the other of the handler. Currently, we only want to log the method calls in the event viewer so we will add the logging handler. In order that the logging handler function properly, we also need to add the logging application block. Now we need to add when these handlers should be fired. For the current scenario, we would like to see the firemethod1 call logged when the method is called. So we add the member name matching rule and add the member name in the matches collection.

No we are all set. In the code, we just need to call the PolicyInjection static class to create the object. This class ties up the handlers and the rules accordingly. Please note to add the policy injection namespace in the code.

Once you are all done, test the project with the logging handler enabled and without. Whenever firemethod1 is called, you will see an entry on the event logger.

You can add more handlers. Depending on how you add the handlers, the sequence will fire. So it will fire from top to bottom.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

You may also be interested in...


Comments and Discussions

Generalgood article Pin
Donsw30-Jan-09 5:59
memberDonsw30-Jan-09 5:59 
GeneralNice Pin
photonseeder@yahoo.com1-Nov-08 2:07
memberphotonseeder@yahoo.com1-Nov-08 2:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web01 | 2.8.190306.1 | Last Updated 20 Mar 2009
Article Copyright 2008 by Shivprasad koirala
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid