Is there any way I can get the context so I can retrieve the loggerName
and use LogManager.GetLogger(loggerName)
instead of LogManager.GetCurrentClassLogger()
?
I noticed container.RegisterConditional()
has access to the context.
Also, I want to avoid solutions like SimpleLogging.NLog for now.
Finally, I am willing to accept this is not the right approach. BTW, AOP is an option that I've already explored (Is it a good practice to have logger as a singleton?).
Note: I am aware that GetCurrentClassLogger()
gets the same information I'd retrieve with .NET reflection.
using NLog;
using SimpleInjector;
namespace DependencyInjection
{
class Program
{
private static Container _container;
static void Main(string[] args)
{
Bootstrap();
_container.GetInstance<Greeter>().Greet();
}
private static void Bootstrap()
{
_container = new Container();
_container.Register<ILogger>(() => LogManager.GetCurrentClassLogger(), Lifestyle.Transient);
_container.Register<Greeter>();
_container.Verify();
}
public class Greeter
{
private ILogger _logger;
public Greeter(ILogger logger)
{
_logger = logger;
}
public void Greet()
{
_logger.Log(LogLevel.Info, "Hello world!");
}
}
}
}
You need to define a proxy logger which routes the message to the correct Nlog Logger. This proxy is pretty simple:
You can register this as
Everywhere you need logging you only will have to inject
ILogger
.As for AOP. I'm unsure what you mean by this comment
Logging is a cross cutting concern and using a decorator is a great way to apply cross cutting concerns. With a decorator it won't be possible to log every (private) function call entrance and exit but why would you want that? As you can read here you probably don't need that. The simple fact that a service is called (with the data passed to this service) and possible exceptions are logged with the complete stacktrace will be more than sufficient in most cases.
So consider this:
This decorator will log all function calls with the information passed to the service and will also log any exception.
But this approach would increase the number of classes by 2, so not very DRY. This problem is caused because this design is at least suboptimal. Using a design around a single open generic abstraction will totally solve this problem. You can read about this design here and here.
In this case you would have a single `LoggingDecorator' as
And this single decorator will log all your commands.
That's my vision of AOP....