Interception in Microsoft Unity framework for .Net

Introduction

This article is to demonstrate how we can combine dependency injection framework with logging og low level execution flow of application.

Prerequisites

• Knowledge about dependency injection.
• Knowledge about unity from Microsoft for dependency injection

Background

If we develop any application, logging is an essential thing to troubleshoot issues which comes in  later stages. Ideally there should be no bugs in production, if we test well. But it is not practical 99.99% of times. Sometimes even if there are no defects we may need to understand how the system is getting used. We call it as instrumentation, telemetry etc...Whatever we call, we have to make sure our application is capable of telling us what it did. Writing log lines inside our business logic has more efforts/costly, makes it longer and very difficult to read. 

Instrumentation technology considerations

Below are the factors to be considered when we select any logging and instrumentation technology for software.

• Performance - Due to the logging operations our application should not be performing slow. Logging is for application not the other way.
• Controlling behavior - We should be able to turn the logging on and off without restarting the application. Also change the level of logging without restarting.
• Compatibility - If our system spans across different technologies better choose one which works everywhere.

Options

Traditional options include inserting log lines at the beginning and end of every methods and additional lines if the logic inside complicated. Another option is to inject the logging code at runtime. Both has their own pros and cons.

Few words on ideal composed application

If we look at SOLID principles we could see that all it tells us is to develop apps in a modular way where modules can be composed easily. In other words single responsible, closed components connected together to become an application. When we say modules, components in general they all translate to classes or functions in code.

How we compose the application by connecting the components is via dependency injection framework.

Combining DI framework and logging

Now most of the people might have got the click of idea. If the application follows SOLID principles religiously, why can't our DI framework log the method calls as it knows how application is composed. When we say how the application is composed it is same as the application flow which we need to log.

This is supported in Microsoft unity framework which provides DI capabilities for .Net. There are other DI frameworks available, one other called MEF which is native to .Net itself. This post is not to discuss what is the best DI framework but on the possibilities of combining DI with function level logging.

Steps in general

• Have a interceptor mechanism which can tell us what is happening in the DI framework
• Let the interceptor log the details into appropriate medium using best technology.
• Register the interceptor into the DI framework.

Understanding sample

Coming directly to the sample which is available in the below location.

https://github.com/joymon/dotnet-demos/tree/master/patterns-practices/DI/unity/Interception

class LogCallHandler : ICallHandler

This is the interceptor we have written. It has Invoke() implemented which came via ICallHandler. Invoke() will be called by the unity DI framework when things happen there.

This is one mechanism unity supports. There are other ways to hook interceptors.

UnityConfiguration.xml

This is the configuration file which tells the unity framework about the components and how they composed. In simple words when someone request object of x interface give object of y class which implemented x. This file also has options to register interceptor.

This configuration can be specified via code too.

class Logger

This is a simple logger class which logs via .Net trace. .Net tracing is configured in the sample to write to file.Refer app.config file. We have to consider intercepting the method calls and writing the logs separate. If our log writing takes more time the performance of application may get affected. Choosing log writing mechanism is not in the scope of this article. In short, recommended mechanisms are ETW for on premise and Application insights for Azure environments.

References

https://msdn.microsoft.com/en-us/library/dn178466(v=pandp.30).aspx
http://mohtasebi.com/patterns/2013/10/24/using-unity-for-aspect-oriented-programming-and-interception-part-1.html