Designing to a common interface - Application loggers for SharePoint and ASP .NET

Last week I decided to start working on an application that I am planning to release as an open source initiative. My contribution will not be a framework but rather an application that will help schools to manage their information in a better way.

As I am slowly starting to work on the design of the application I started by tackling one of the Cross-cutting concern: Logging.

It is a good practice to centralized your logging code so if there are changes on the requirements, for the logging of your application, it will be easier to perform these changes.

Consider the case where an application was originally developed with logging to files, on the file system. If there is a change on the logging requirement, say the application needs to write its logs to a Oracle or MSSQL database tables, how easy is to change the code of the application to accommodate this new requirement?

If the logging functionality is scatter all over the different layer of the application then the changes will required a greater effort. On the other hand if the logging functionalities are centralized then the changes are isolated requiring less effort.

When building modules and applications it pays off to develop them having in mind 'Anticipation of Change'.

So I want to have my logging functionality centralized as much as possible and would love to have a common or related logging API for ASP .NET and SharePoint.

After some thinking I came up with the following design

 The logger to be used for SharePoint and ASP .NET implement a common interface. The interface ILogger and the classes that implement this interface , the SharePointLogger and WebLogger, can be built into the same assembly providing a common library that can be shipped for both platforms.

The SharePoint logger inherits from the SharePoint class SPDiagnostServcieBase. Inheriting from the SPDiagnosticsServiceBase allows us to have our own custom diagnostic categories and use the WriteTrace and WriteEvent methods to perform logging. You can read it up more about the SPDiagnosticServiceBase class here

The WebLogger on the other hand contain a logger property that can be an a type of a .NET logger library or framework such as Log4Net.

How the SharePointLogger and WebLogger implements the logging of errors and messages is abstracted from their clients, the classes our component using the logging API. 
In fact we could change the .NET library used by the WebLogger and that shouldn't affect other layers of the application such as the Database layer as long as the interface contract remain the same. The interface contract in this case being the methods Log(String category, String message) and LogError(String category, String message).

This design achieves the objective of centralizing the logging functionality for the application. It also makes it possible to ship the loggers to both platforms ASP .NET and SharePoint.
As an added bonus, we all like bonuses,  this design abstracts the logging logic away from other classes/components.

Many of the concepts that help us to write  re-usable code have its root on sound Software Engineering principles and programming paradigm such as OOP (Object Oriented Programming) help us to implement these principles.

On this note, I would like to recommend you  Fundamentals of Software Engineering (2nd Edition) by Carlo Ghezzi, Mehdi Jazayeri,Dino Mandrioli

This book is timeless and highlight the good principles of developing re-usable and robust software. A good companion book for any serious developer that views writing code as a Craft.

This link to a PDF lecture will give you a highlight of the third chapter of this book where it briefly mention the Software Engineering principles. Other chapters, of the book, dive-in deep into these principles and how to apply them.

We can be agile and write good code. ;-)