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