0
votes

When looking around for a logging framework (log4net, NLog, etc), I find that most of them conform to a very basic interface. The Common.Logging interfaces are a good away to create an abstraction and single contract, through the use of adapters and whatnot, between logging frameworks and your code. Common.Logging provides the following interface (summed down):

void Trace(object message);  
void Debug(object message);  
void Info(object message);  
void Warn(object message);  
void Error(object message);  
void Fatal(object message); 

For application logging, would we not want something more expressive and explicit?

For example, I may want to log more fields. Perhaps I want an "Method" or "Context" field? Maybe I really don't like the naming conventions of these methods. They are not verbs; something which violates our standards. This also provides perhaps too much flexibility - who knows how each developer will treat logging.

For that reason, I am tempted to wrap Common.Logging with something more explicit:

void LogTrace(string context, string message, string parameters);
void LogDebug(string context, string message, string parameters);
void LogInfo(string context, string message, string parameters);
void LogWarning(string context, string message, string parameters);
void LogError(string context, string message, string parameters);
void LogError(string context, string message, string parameters, Exception ex);
void LogFatal(string context, string message, string parameters);
void LogFatal(string context, string message, string parameters, Exception ex);

Is this advisable and are there any drawbacks to such approach?

2
I do not see the advantage. You are not abstracting you specify. The Methods with object message are most abstract as possible. Of course you can put your API on top of that to get a type-safe api. You know that your message will be serialized into an string, so why do you have to have explicit parameters? Use an anonymous type or a "LogMessageType". Build a new API for logging, but it's application specific and not "abstract". Take a look at: github.com/damianh/LibLog - Stefan Ossendorf
@StefanOssendorf: Apologies. Updated question. I want to essentially wrap, not abstract. - Dave New

2 Answers

1
votes

By using a wrapper around your different logging frameworks you will only using the common functions of the logging frameworks. Each logging framework has its strong and weak points, in most cases you should choose the logging framework based on the requirements for logging and look at those points.

1
votes

Did you consider Anotar under Fody instead of Common.Logging? Each of the methods, Trace, Debug, Fatal, etc., has the expected 'message', 'params' and 'exception' overloads. Like Common.Logging it is easy to switch between logging libraries.