Selecting IoC framework

Vagif Abilov — Tue, 27 Oct 2009 09:10:04 GMT

No, I haven’t chosen one to use yet. But I kind of feel that instead of investing more time in home-made and fairly inefficient DI classes, I should rewire the code to use one of the available IoC frameworks. And here are some blog posts that can help to make a choice.

Comparing .NET DI (IoC) Frameworks (part1 and part2) by Andrey Shchekin. Very good comparison with source code uploaded to Google Code.

IoC libraries compared by Chirs Brandsma. Focuses on most common case - constructor injection. Source code is also available.

Having read these two posts, I’d probably go with either StructureMap or Autofac. But I would also like to have a closer look at MEF that was not covered in these blog posts (I guess because it’s not a pure IoC container). Here’s an excellent Ayende’s post explaining why.

Dependencies without injection

Vagif Abilov — Thu, 17 Sep 2009 09:32:53 GMT

Logging is one of the most popular areas used as example to illustrate dependecy injection technique. Components need to log their activities, and to remove hard dependency on actual logger implementation, it’s reasonable to define an interface (something like ILog) that is sent to class constructors, thus freeing components from knowledge about logging details.

Unfortunately things are different in practice. And if your application uses several third-party libraries that depend on different logging frameworks, you are often out of luck if you try to harmonize their logging and route its output to common log sinks (or listeners).

Take for example log4net. It’s LogManager looks DI-compliant: it has a method GetLogger that returns an instance of ILog interface:

ILog log = LogManager.GetLogger(“MyLog”);

You would then expect a way to configure LogManager to return a custom logger. Nope! You can’t control that. log4net does not give you a chance to write your own logger.

But isn’t this wish outside log4net purpose? Since ILog interface is not a generic .NET interface but a contract that is defined by log4net, isn’t it fair to assume that log4net will use its own logging engine leaving possibilities to write custom appenders? Well, as long as log4net is the only third-party component that you use, this will be sufficient. Once you add more, this can become a problem.

Our components use Enterprise Library Logging Application Block for its logging purposes. Recently we started using WCF and NHibernate and would like to aggregate all log output. Not an easy task.

With WCF it seems that there is a way to redirect its logging. There is a special log listener called EntLibLoggingProxyTraceListener used as a bridge between WCF log messages and Enteprise Library LAB. But NHibernate uses log4net, and it looks that the only way to route NHibernate logs to our listeners is to write a special appender. The effort to write such appender is not more complex than to write a custom implementation of ILog interface. I just believe that if a framework provide all necessary elements to fully implement dependency injection pattern (interface definition, factory), it should make the last step and make class instantiation configurable, opening for external implementation of the class.

Vagif Abilov's blog on .NET : Dependency injection

Selecting IoC framework

Dependencies without injection