Plug & play architecture using policy application blocks

Introduction

In this section we will discuss how we can make plug & 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 past some days I have been writing and recording videos for architecture and project managers. You watch the videos here.

Problem

To understand the real use of policy application blocks we will take up a real time 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 DLL’s and it will be very difficult to track down the errors. We can definitely use TRACE to get to the bottom of the problem. One of the issues with TRACE is that we do not get verbose information. From trace we will just get which method has the issues.

Below is a solution which I have thought I am sure there are better ways of doing it. The whole point of this article is to make 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 the debug mode we will just plug in the logging application block. The logging application block will start logging in method calls in event log which we can use to analyze what issue we have in the application. In the 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.

 

Solution

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

Implementation

In order that the class methods can be monitored by the policy block we need inherit the class from an interface. For the current example we want to monitor any methods of class clsFireMethods. You can see we have inherited the same from a 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 is the handler. Currently we only want log the method calls in event viewer so we will add logging handler. In order that logging handler should 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 firemethod1 call logged when the method is called. So we have added the member name matching rule and added 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 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.