title: Granularity of application logging
body: <p>Most developers strongly recommend that whatever logging framework you use (log4net, NLog, MS Diag, etc) that you do do two things:</p>
  
  <p>1)implement class-specific loggers for granularity rather than sending everything thru a Singleton
  2)Create a facade for your logging framework to mask the actual framework choice (so that you can swap out log4net for NLog seamlessly for example)</p>
  
  <p>The second one I dunno how much I buy into, it seems like a perfect example of over-engineering a solution. For example, I 'could' write my application to be completely database agnostic and capable of hooking up to any database provider. But how often is that necessary in practice? 95% of the time you pick your target database type and you stick with it and for me a logging framework is the same thing, I've chosen NLog and that's what I intend to go with for the life of the project. If in 5 years I need to switch it out then they'll likely be a bunch of other stuff that I'll need to change too so I'll do it as part of the rewrite.</p>
  
  <p>The first item though seems like it could have useful application though. Can someone provide me of some specific examples of how they might exploit this feature? How would you implement that in practice? Like say I have a dataaccess module that is suddenly failing for some unknown reason...how would I modify my logging settings on the fly to focus in on that module and get verbose logging info? Is their a programmatic means to tell NLog to reload its settings while the app is running?</p>
  
  <p>thanks </p>