Difference Between Logger and LogWriter

Question

I am using the Microsoft Enterprise Library 5.0 Logging block and I wanted to know the difference between the LogWriter and the Logger classes. I have a few custom trace listeners that I have built to be used in my logging and I wanted to know if using Logger vs. LogWriter would have any effect.

From MSDN http://msdn.microsoft.com/en-us/library/microsoft.practices.enterpriselibrary.logging.logwriter.aspx

To write log messages to the default configuration, use the Logger facade. Only create an instance of a LogWriter if you need to write log messages using a custom configuration.

Example code #1:

namespace ExampleOne
{
    using System;
    using System.Diagnostics;
    using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
    using Microsoft.Practices.EnterpriseLibrary.Logging;

    public class Program
    {
        private static LogWriter logger = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();

        public static void Main(string[] args)
        {
            try
            {
                throw new Exception("My test exception message");
            }
            catch (Exception ex)
            {
                LogEntry logEntry = new LogEntry();
                logEntry.Message = "Error: " + ex.ToString();
                logEntry.Categories.Add("General");
                logEntry.Severity = TraceEventType.Error;
                logger.Write(logEntry);
            }
        }
    }
}

Example code #2:

namespace ExampleTwo    
{
    using System;
    using System.Diagnostics;
    using Microsoft.Practices.EnterpriseLibrary.Logging;

    public class Program
    {        
        public static void Main(string[] args)
        {
            try
            {
                throw new Exception("My test exception message");
            }
            catch (Exception ex)
            {
                LogEntry logEntry = new LogEntry();
                logEntry.Message = "Error: " + ex.ToString();
                logEntry.Categories.Add("General");
                logEntry.Severity = TraceEventType.Error;
                Logger.Write(logEntry);
            }
        }
    }
}

Answer 1

The version that get's current instance is part way to being the better version because it would be easier to use dependency injection & hence make it easier to unit test incase the logger writes to the db or sends email or otherwise interacts with some large external component that has behavior unrelated to the code under test.

On the other hand, if the goal is to encourage logging on your team, then logging with minimal set up is the better option, but config will be config file driven & you'd need a separate config file for tests vs production.

Also, in real life organizations, you can't always expect the operations people to be web config (or in this case Ent Lib config) super ninjas and sometimes you need to provide UI that turns on logging and turns off logging or otherwise changes the behavior (like sending errors to a different mailing list/list of users) and that will require dynamic config. I've worked in organizations when changing logging behavior via UI was just an ordinary transaction but changing so much as a character of the web.config took a frickin act of god and the change control board.

Answer 2

There is no difference between using the static Logger.Write() facade and using the Write method of LogWriter.

Here is what Logger.Write does:

public static void Write(LogEntry log)
{
    Writer.Write(log);
}

Where Writer is an instance of LogWriter. Logger.Write() is provided for backward compatibility with previous releases of Enterprise Library; the preferred approach is to use a LogWriter instance mainly because of enhanced testability.

From Creating and Referencing Enterprise Library Objects:

The legacy static facades and factories that were the default approach in versions of Enterprise Library prior to version 5.0 are still available, and continue to be supported for the purpose of backwards compatibility. However, new code should use either the service locator approach or the techniques for accessing the container directly, as described in previous sections of this topic.

Based on the posted exception logging examples you may want to consider using the Exception Handling Block along with Logging so that developers don't even have to log -- just handle the exception. You might be able to use the Process method to wrap calls so that no code is required in the called methods:

ExceptionManager em = EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>();
em.Process( () => MethodThatMightThrow(), "My Logging Exception Policy"); 

Another approach might be to use interception along with an ExceptionCallhandler.

Both of these approaches, although slightly limiting from a design perspective, enable exception logging to be entirely hidden from developers so that they can focus on writing the application instead of boiler plate logging code.