1
votes

I've recently been learning about inversion of control through dependency injection, and using Castle Windsor. I like it. I get it. The lightbulb over my head is burning brightly. But I have a nagging concern about the logging facility and the ILogger interface. What is that really doing there? Is it for me, or just for Windsor itself?

Since ILogger is intended to abstract away the differences between log4net and Nlog and whatever other logging frameworks it supports, it has to represent the lowest common denominator between them. The various frameworks are similar, but not necessarily identical. If there were some fantastic feature in one, but not in the other, it would either have to be left out of ILogger, or the ILogger implementations for the other logging frameworks would have to have no-op implementations of it, or something else that's not very satisfying.

Long before Windsor, I was a fan of log4net, and a lot of my favorite libraries use it, like NHibernate. So if I'm building a new application, I'll use log4net. I'm willing to commit to it, and I consider it a stable dependency -- as stable a dependency as needing System.Web for example. I would not write my components to use ILogger, I would write them to use ILog. But I get the impression that Windsor expects me to use ILogger for my own logging. Isn't that saddling my project with a dependency on Windsor, when I shouldn't have any dependency on my IoC container?

I see the point of Windsor having the logging facility so it can log its own operations using whichever logging framework the project wants to use. That seems perfectly sensible. But if I don't use ILogger for my own code, and just go straight to log4net's ILog, what am I giving up? Will I regret this?

The obvious response is that I might want to change logging frameworks in six months. But I won't. log4net is mature and stable. It's a project with a limited and very well-defined scope, which it implements nearly perfectly. It can be considered "finished". At most, I might need to write a custom appender to handle messages. (Maybe I want to write them onto a postcard and drop them in the mail for some reason.) But that's easily done within the log4net framework, and I would use it just like any other log4net appender. I would be no more likely to change logging frameworks than I would be to change web platforms.

1

1 Answers

0
votes

It seems as if you have already made your mind up to use log4net directly. This is perfectly reasonable, as you consider it to be a stable dependency. I have just switched from log4net to NLog for our projects, so it does happen that you may change logging frameworks in future, which is where an abstraction has its advantages.

Another consideration when thinking about using a logging abstraction (other than losing functionality specific to a particular logging framework), is the extra overhead of learning the abstraction. Does this make the code more or less complex for developers to pick up?

In our case, we found NLog was so easy to install and configure directly, that we decided to lose our custom logging abstraction and switch from log4net (which we found a bit verbose in its xml configuration compared to NLog).