Question

on our current project we decide to use enterprise library for logging, upto now we used only log4net, but I can not find any advice how to really use the library in flexible way, what I mean is in log4net this would be the way:

//define this in MyClass
private static readonly ILog log = LogManager.GetLogger(typeof(MyClass));
//and than in the methods you can call it like this 
log.Info("info message");

this would enable me to go to application later and by chainging configuration I could turn info/warn levelels for particular classes without touching the application.

The only sample of logging library is basically this:

LogEntry logEntry = new LogEntry();
logEntry.EventId = 100;
logEntry.Priority = 2;
logEntry.Message = "Informational message";
logEntry.Categories.Add("Trace");
logEntry.Categories.Add("UI Events");
Logger.Write(logEntry);

but than I would be bound to filter based on some strings with typos and similar, and every developer would introduce his category-tokens, what is the best way to limit this, what are best practices about constructing messages, on another side above solution is not very developer friendly to require 10 lines for single log message, using some static methods for whole solution would reduce flexibility in filtering, so what is the best way to use logging?
did you found any meaningful pattern how to use it?

thanks
almir

Answer 1

Your question touches on one of the “issues” of Enterprise Library. Sure, it just works (with some configuration headaches usually), but if you want something with a bit of structure it’s not there. Plus there is not much guidance out there from Microsoft.

Here’s what I would do:

• I would add a facade to the Logging Block that lets you control how you want to log your data. i.e. if you don’t want developers creating their own categories, have your facade take an enumeration (you can mark it as Flags to allow multiple categories).

• I would get rid of Priority since I don’t think it buys very much considering you also have Severity and Category to filter on.

• You also might want to add overloads to support Exceptions and ValidationResults (if you are using Validation Application Block).

• Another feature you might want to have is adding the class name as a category to support logging for particular classes. You could either have the developers pass in the class name or you could determine it through reflection. I prefer passing it in.

So you could do something like this:

[Flags]
public enum EventDataTypeCategory 
{     
    None = 0x0,   
    Failure = 0x1,
    Error = 0x2 ,
    Warning = 0x4,
    Information = 0x8,
    Debug = 0x10,
    Trace = 0x20,
    UIEvents = 0x40,
    DataAccess = 0x80
}

public static void LogMessage(string message, string className, int eventId, 
    EventDataTypeCategory categories)
{
    // Create LogEntry
    LogEntry logEntry = new LogEntry(...);

    // Add all categories
    foreach (EventDataTypeCategory enumValue in System.Enum.GetValues(typeof(EventDataTypeCategory )))
    {
        if ((enumValue & categories) == enumValue )
        {
            logEntry.Categories.Add(enumValue.ToString());
        }
    }

    if (className != null)
    {
        logEntry.Categories.Add(className);
    }

    ...

    Logger.Write(logEntry);
}

Then you could call it like this:

public class MyClass
{
    private static readonly string ClassName = typeof(MyClass).FullName;

    public void DoSomething()
    {
        MyLogger.LogMessage("I'm going to DoSomething now!",
            ClassName, 
            1001, 
            EventDataTypeCategory.Trace | EventDataTypeCategory.UIEvents);
    }
}

If that’s still too many arguments then you can have an overload that takes less parameters and provides defaults for the other values. e.g. if you don’t care about EventIDs default it to 0.