Plug & play architecture using policy application blocks

Table of Contents

• Introduction
• Other Application Blocks
• Problem
• Solution
• Implementation

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.

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 short comings in VAB is that it does only server side validations. This article talks how we can leverage VAB for client side.Client side validation

Dynamic validation: - This article explains how to build dynamic validation on scenario basis.Dynamic validation

Logging application block: - This article explains the 5 basic steps of how 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 application talks how we can use exception application blocks to log exception from project.Exception application block

Unity application block: - This application talks about 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

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.