Dependency Injection (DI) and Inversion of Control (IoC) are popular patterns in modern software development that reduce coupling among modules and so improve the testability of the sames. As this article is not meant to be an introduction to DI / IoC, please refer to numerous introductory articles on the net before tackling this topic, as we will delve straight into the implementation's details. For these samples, we will use Castle Windsor as IoC container, and we will build the same sample three times, highlighting the differences in handling permanent and transient class instances with an IoC container. The aim is creating an implementation that has minimal coupling and is highly testable.
Let's start by drawing the scenario: our simple app uses the IoC container for cross-cutting concerns, in this example only logging but in a real app there could be a lot more functionalities of this kind. e.g. data model access, telemetry and so on. The logging framework is a singleton that spans the whole life of the app, so once we register the interface in the IoC container, and let the container inject the instance into the objects that use it, we are golden. But temporary objects, like a child window, are created and then destroyed when needed, so the same instance cannot span the whole life of the app. At the same time, these temporary objects need to access the functionalities such as logging, so those instances must be injected into the freshly created object.
Let's start with the first implementation to see some real code (before proceeding, download the whole solution from GitHub). The project ManualIoC contains a poor man's implementation of DI, as we have to manually pass the instances to the transient objects. First, let's start with the main program, where we initialize the IoC container:
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
// create IoC container
IWindsorContainer container = CastleContainer.Instance;
container.Register(Component.For<ILogger>().ImplementedBy<ConsoleLogger>());
container.Register(Component.For<MainForm>());
//Application.Run(new MainForm());
MainForm mainForm = container.Resolve<MainForm>();
Application.Run(mainForm);
container.Dispose();
}
There are several changes compared to a stock WinForms application: before creating the main form of the app, we create the IoC container, and we register the implementation of the ILogger service, and the MainForm class. Instead of creating directly the MainForm like it happens with the standard WinForms code, we ask the IoC container to resolve, that is returning an instance of the given class, the MainForm and then we run the application. The critical bit is that MainForm requires an ILogger instance in the constructor, and the IoC container knows about it, so it transparently creates a singleton for the ILogger interface using the ConsoleLogger implementation and passes it to the constructor of MainForm, without requiring any intervention from our side. With a simple demo it is hard to understand how an IoC controller can simplify a real project, but assume that there is not just one cross-cutting functionality like logging in the example, but many more and you will understand how the code gets clearer and simpler. Also, rewiring the app to use a different logging framework requires just creating a new implementation of the ILogger interface that uses the new framework, and changing just the registration of the ILogger interface in this bit of code.