I love Ninject, and I love log4net. I tend to pull them in to any project that I’m working on. And Ninject provides great support through its Ninject.Extensions.Logging package for getting log4net loggers injected into your classes with very little work. But one thing always bugged me: you have to put an [Inject] attribute on every ILogger property that you want injected. I hate that, because it scatters Ninject all over your implementation classes, and as a general rule your classes should be agnostic toward whatever IoC container you happen to be using. So, I created the NinjectAutoLogging package to allow for automatically injecting ILogger properties without the need for the attribute.
This is part three in a series of articles on .NET architecture. You can start here for the introduction and table of contents. This post will focus on the first thing you should think about when starting a new .NET application: cross-cutting concerns. And, by the way, I got really tired of type “cross-cutting concern” after about a dozen times, so I decided to coin a new acronym for them: C3s. I hope you like it.