I want to use a nlogger in my application, maybe in the future I will need to change the logging system. So I want to use a logging facade.
Do you know any recommendations for existing examples how to write those ones ? Or just give me link to some best practice in this area.
I used to use logging facades such as Common.Logging (even to hide my own CuttingEdge.Logging library), but nowadays I use the Dependency Injection pattern. This allows me to hide loggers behind an application-defined abstraction that adheres to both Dependency Inversion Principle and the Interface Segregation Principle (ISP) because it has one member and because the interface is defined by my application; not an external library.
Minimizing the knowledge that the core parts of your application have about the existence of external libraries, the better; even if you have no intention to ever replace your logging library. The hard dependency on the external library makes it more difficult to test your code, and it complicates your application with an API that was never designed specifically for your application.
This is what the abstraction often looks like in my applications:
public interface ILogger
{
void Log(LogEntry entry);
}
public sealed class ConsoleLogger : ILogger
{
public void Log(LogEntry entry)
}
public enum LoggingEventType { Debug, Information, Warning, Error, Fatal };
// Immutable DTO that contains the log information.
public struct LogEntry
{
public LoggingEventType Severity { get; }
public string Message { get; }
public Exception Exception { get; }
public LogEntry(LoggingEventType severity, string msg, Exception ex = null)
{
if (msg is null) throw new ArgumentNullException("msg");
if (msg == string.Empty) throw new ArgumentException("empty", "msg");
this.Severity = severity;
this.Message = msg;
this.Exception = ex;
}
}
Optionally, this abstraction can be extended with some simple extension methods (allowing the interface to stay narrow and keep adhering to the ISP). This makes the code for the consumers of this interface much simpler:
public static class LoggerExtensions
{
public static void Log(this ILogger logger, string message) =>
logger.Log(new LogEntry(LoggingEventType.Information, message));
public static void Log(this ILogger logger, Exception ex) =>
logger.Log(new LogEntry(LoggingEventType.Error, ex.Message, ex));
// More methods here.
}
Because the interface contains just a single method, it becomes easily to create an ILogger implementation that proxies to log4net, to Serilog, Microsoft.Extensions.Logging, NLog or any other logging library and configure your DI container to inject it in classes that have a ILogger in their constructor. It is also easy to create an implementation that writes to the console, or a fake implementation that can be used for unit testing, as shown in the listing below:
public class ConsoleLogger : ILogger
{
public void Log(LogEntry entry) => Console.WriteLine(
$"[{entry.Severity}] {DateTime.Now} {entry.Message} {entry.Exception}");
}
public class FakeLogger : List<LogEntry>, ILogger
{
public void Log(LogEntry entry) => this.Add(entry);
}
Having static extension methods on top of an interface with a single method is quite different from having an interface with many members. The extension methods are just helper methods that create a LogEntry message and pass it through the only method on the ILogger interface. These extension methods themselves contain no Volatile Behavior of themselves and, therefore, won't hinder testability. You can easily test them if you wish, and they become part of the consumer's code; not part of the abstraction.
Not only does this allow the extension methods to evolve without the need to change the abstraction, the extension methods and the LogEntry constructor are always executed when the logger abstraction is used, even when that logger is stubbed/mocked. This gives more certainty about the correctness of calls to the logger when running in a test suite. I've shot myself in the foot with this many times, where my calls to the used third-party logger abstraction succeeded during my unit test, but still failed when executed in production.
The one-membered interface makes testing much easier as well; Having an abstraction with many members makes it hard to create implementations (such as mocks, adapters, and decorators).
When you do this, there is hardly ever any need for some static abstraction that logging facades (or any other library) might offer.
Still, even with this ILogger design, prefer designing your application in such way that only a few classes require a dependency on your ILogger abstraction. This answer talks about this in more detail.
LogEntry constructors". Since you need to pass a LogEntry, you still need to know how to create one. So basically the interface is still as broad as before. The wikipedia article you link to states "ISP splits interfaces which are very large into smaller and more specific ones (...)" - there is no splitting going on here. There is merging - which i agree to be quite beneficial for the logging abstraction. –
Twocycle ILogger interface adheres to the ISP. It has to be, since it only contains one method. But remember: I didn't say anything about LoggerExtensions and how it relates to the ISP :-). Also note that consumers typically don't have to worry about creating the LogEntry class, since creation is done for you by the extension methods. –
Superman LoggingEventType enum to something that is specific for the underlying logging framework. There are several ways to do this; a switch-case is one of them. –
Superman LoggingEventType your own enum? I can't find it anywhere :/ –
Seating LogEntry objects when the severity is disabled. So, the insterface should contain something like IsEnabledFor(LoggingEventType severity). And maybe struct LogEntry could be more efficient, too? –
Pragmatics IsDebugEnabled is necessary in the interface when you need to construct some costly, special parameters (strings) for the debug logging and want to disable it in the production. –
Pragmatics I used the small interface wrapper + adapter from https://github.com/uhaciogullari/NLog.Interface that is also available via NuGet:
PM> Install-Package NLog.Interface
As of now, the best bet is to use the Microsoft.Extensions.Logging package (as pointed out by Julian). Most logging framework can be used with this.
Defining your own interface, as explained in Steven's answer is OK for simple cases, but it misses a few things that I consider important:
IsEnabled(LogLevel) which you might want, for performances reasons once againYou can probably implement all this in your own abstraction, but at that point you'll be reinventing the wheel.
A great solution to this problem has emerged in the form of the LibLog project.
LibLog is a logging abstraction with built-in support for major loggers including Serilog, NLog, Log4net and Enterprise logger. It is installed via the NuGet package manager into a target library as a source (.cs) file instead of a .dll reference. That approach allows the logging abstraction to be included without forcing the library to take on an external dependency. It also allows a library author to include logging without forcing the consuming application to explicitly provide a logger to the library. LibLog uses reflection to figure out what concrete logger is in use and hook up to it up without any explicit wiring code in the library project(s).
So, LibLog is a great solution for logging within library projects. Just reference and configure a concrete logger (Serilog for the win) in your main application or service and add LibLog to your libraries!
Generally I prefer to create an interface like
public interface ILogger
{
void LogInformation(string msg);
void LogError(string error);
}
and in the runtime i inject a concrete class that is implemented from this interface.
LogEntry, and thus a dependency on LoggingEventType. The ILogger implementation must deal with these LoggingEventTypes, probably though case/switch, which is a code smell. Why hide the LoggingEventTypes dependency? The implementation must handle the logging levels anyway, so it would be better to explicit about what an implementation should do, rather than hiding it behind a single method with a general argument. –
Crine ICommand which has a Handle which takes an object. Implementations must case/switch over possible types in order to fulfill the interface's contract. This isn't ideal. Don't have an abstraction which hides a dependency that must be handled anyway. Instead have an interface that states plainly what is expected: "I expect all loggers to handle Warnings, Errors, Fatals, etc". This is preferable to "I expect all loggers to handle messages which include Warnings, Errors, Fatals, etc." –
Crine LoggingEventType should be called LoggingEventLevel as types are classes and should be coded as such in OOP. For me there is no difference between not using an interface method v.s. not using the corresponding enum value. Instead use ErrorLoggger : ILogger, InformationLogger : ILogger where every logger defines it's own level. Then the DI needs to inject the needed loggers, probably via a key (enum), but this key is no longer part of the interface. (You are now SOLID). –
Marquardt Instead of writing your own facade, you could either use Castle Logging Services or Simple Logging Façade.
Both include adapters for NLog and Log4net.
Since 2015 you could also use .NET Core Logging if you're building .NET core applications.
The package for NLog to hook into is:
© 2022 - 2024 — McMap. All rights reserved.