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

Answer 1

I'm by no means an expert myself, but in our group, the value of the facade is not in giving us the ability to change the logging framework. True, that is something that we get, but we're in the category who is very unlikely to change our framework.

In our case, we are using a facade to tailor the logging interface to the needs of our application. We found that in all the semantic frameworks we looked at, they were still too focused on what we call the "forensics" model of logging--someone digging through the logs looking for some line of output in an attempt to analyze some event.

While this is a use case for us as well, it is actually not our primary use case. We want more of an instrumentation framework than a logging one, which will allow us to report on things of interest--even ones we haven't thought of at implementation time.

For example, our application doesn't need a "message" to accompany an event; instead, our "logger" will accept enums defining the event type and state objects representing specifics (eg. timestamps or other values) and will serialize these to facilitate reporting, perf analysis, business value metrics and so on, all in addition to supporting traditional forensics. (We recognize that we are, in fact, making the traditional forensics a little harder for the benefit of a simple-to-use-and-understand logging interface that increases the likelihood that we will actually use it and use it more often).

So to give you a summary answer succinctly, here's a roughly ranked order of the benefits we feel we're getting from using a logging facade.

1. Consistent, purpose-built interface facilitating instrumentation (as opposed to just traditional logging, as discussed above)
2. Mockable test points
3. Injectable logger implementations suitable for everything from local development to AWS S3 or DB connections, depending on deployment (our app uses Autofac with constructor dependency injection)
4. Substitutable logger frameworks enabling us to change to a different logger framework in the future if we want to. (Incidentally, we don't forsee this happening, so, on its own, wouldn't have convinced us to use a facade.)

And finally, 0 facades would lose these benefits, and 2 facades would not add to any of these benefits, so that's why 1 facade is the right number for us.

Great question, @brian! :)

Answer 2

In this example you only need one level of abstraction to be able to swap out your logger.

What additional advantage would being able to swap out your logging facade get you?

Answer 3

I think what makes One (level of abstraction) the magic number here is that Zero is too few and Two is too many.

Swapping a logger behind a logger facade (number of levels: 1) can possibly result in some user benefit, such as the new logger can do something that the old logger can't. I can imagine that it could be performance, supporting certain types of appenders, etc.

It's much harder to imagine the user benefit from swapping a logger facade (number of levels: 2).

(And if the number of levels is 0, then it's probably just bad object-oriented design: you'll have thousands of places in your code where the logger is referenced and what if there's a breaking change in the next version of the logger.)

The deal with logger facades appears to be that you have to pick one of the third-party options or to create your own and prepare to stick with it for a long time.

Answer 4

An important use of a logging facade is when you're writing a library. Embedding dependencies in a library is always something that requires a bit of care, and logging even more so.

In short, you don't want to force your logging implementation onto your library users. Using a well-chosen facade means they'll be able to handle your library's logs with their own framework of choice and won't have to go through some weird dependency exclusions and loopholes to make both your logging framework and theirs coexist.

Answer 5

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.

Answer 6

It is usable in protocol for plugin system. Instead of saying use Some3rdParty.dll and MyPlugingApi.dll I would document only MyPlugingApi.dll. Log facade interface will suggest and document some usage that probably will lead to readable logs and good enough logging performance. And of course doing changes will not lead to changes to plugin API.

Why need to change implementation? This can happen if current appears to slow to start out of config or slow to write entries, desire to expand to cut down version of .NET which does not have needed 3rd party, integrating with other codebase which uses other log writers.

I also have written yet another facade which is child of thoughts in this answer.