What's the point of a logging facade? [closed]

Question

There are a bunch of different logging libraries to choose from, each with their own set of quirks and advantages. (.Net examples: log4net, System.Diagnostics.TraceSource, nLog, etc.)

The natural inclination is to abstract away those quirks and use a logging facade. (examples: Castle.Services.Logging, Common.Logging, Simple Logging Facade) That way, if a given logging framework that you're using goes stale, or a different one comes into vogue, you can just swap out the implementation and leave the code untouched.

But there are multiple logging facades to choose from. Given that the answer to many disparate logging implementations was abstraction, why not use a logging facade facade? If that sounds ridiculous, what makes it more ridiculous than the original logging facade? What makes one extra layer of abstraction on top of the logging framework the magic number?

Answer 1

Until NLog and log4net provide an interface that can be used instead of the concrete classes, I've always abstracted them behind my own interface and wrapper class.

Why?

To gain the most test coverage of all the user requirements, especially when those requirements cover logging.

When you have all of your logging going via an interface rather than a concrete class, it becomes very easy to provide a mock object with the logging interface (pick your choice of how you do that, dependency injection etc..) to record all of the logging calls made during a particular test scenario.

These can then be asserted and if a code change breaks the logging your unit tests will cover it.

If NLog or log4Net were to provide an interface for their loggers, then I wouldn't need to go to the effort of providing an interface and wrapper class, since I could just mock their interface for the tests.

Answer 2

It's not the magic number, it depends on how flexible you wanna be. If you think about changing the log facade one day you should write a facade facade. If you think about changing only the log you need one facade. If you don't think about nothing don't use facade.

The disadvantage as you said is the special abilities. If you are using them write your own facade only.

Answer 3

In my project I use System.Diagnostics.Trace.TraceError(...), System.Diagnostics.Debug.Print(...) as facade for logging. For organizing (writing) logs I use NLog, i.e. in app.config I have configuration for NLog and redirection of .net's trace to NLog.

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <targets>
     <target name="file" xsi:type="File"
      layout="${longdate:universalTime=true}Z [${threadid}] ${pad:padding=5:inner=${level:uppercase=true}} ${logger} ${message}"
      fileName="${basedir}/App_Data/logfile.txt"...
   </targets>
</nlog>
<system.diagnostics>
  <trace>
    <listeners>
      <add name="nlog" type="NLog.NLogTraceListener, NLog" />
    </listeners>
  </trace>
</system.diagnostics>

This does not bundle me to any logger. When I ship my components to customers they can use any logger they like. Using particular logger in application could cause problems i.e. you can use nlog but your customers use log4net.