Plug and 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 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.

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.

Problem

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.

Solution

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.

Implementation

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.

For further reading do watch the below interview preparation videos and step by step video series.

• ASP.NET MVC Interview Questions & Answers
• C# Interview Questions with Answers
• Angular Interview Questions with Answers
• Learn Azure step by step.
• Learn MVC 5 Step by Step
• MVC Core Step by Step Tutorial
• SQL Server step by step
• Session & Viewstate in ASP.NET.