Manually implementing IoC with a Windows Service

Question

I am brand new to IoC and thus have been following the examples provided by Jeffery Palermo in his posts at http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ and in his book hosted here https://github.com/jeffreypalermo/mvc2inaction/tree/master/manuscript/Chapter23

Most important to note is that I am not using a pre-rolled IoC container, mostly because I want to understand all the moving parts.

However, I am creating a windows service rather than an ASP.NET MVC webapp so I am little bogged down on the startup portion. Specifically, in the web.config he registers an IHttpModule implementation INSIDE the infrastructure project as the startup module and then uses a post-build event to copy the necessary dlls into the website directory to get around having a direct dependency in the web project itself.

I don't think I have this type of luxury in a true windows service, so how do I achieve something similar, should I have a small startup project which has dependencies to both the Infrastructure and Core, or is there another method to get around the compile-time restrictions of the windows service?

Thanks in advance.

Answer 1

Based on the tags of this question (c#) I'm assuming that you'll implement the Windows Service by deriving from ServiceBase. If so, the OnStart method will be your Composition Root - this is where you compose the application's object graph. After you've composed the object graph, composition is over and the composed object graph takes over.

In OnStop you can decommission the object graph again.

There's nothing stopping you from implementing the various components of the resolved object graph in separate assemblies. That's what I would do.

Answer 2

I think you missunderstood the role of an IoC framework.

To answer your question

but doesn't the reference imply dependency?

Yes it does, but on an other level. IoC is about dependencies between classes. Instead of using new Something() in your class you provide a constructor which requires all dependent interfaces. This way the class has no control which implementation is passed to it. This is inversion of control. The IoC Container is just an aid to help managing the dependencies in a nice manner.

Say you have a ICustomerNotificationService interface with an implementation like

public class MailNotificationService : INotificationService
{
    IMailerService _mailer;
    ICustomerRepository _customerRepo;
    IOrderRepository _orderRepo;

    public MailNotificationService(IMailerService mailer, 
                                   ICustomerRepository customerRepo, 
                                   IOrderRepository oderRepo)
    {
        // set fields...
    }

    public void Notify(int customerId, int productId)
    {
        // load customer and order, format mail and send.
    }
}

So if your application requests an instance of ICustomerNotificationServcie the container figures out which concrete implementations to take and tries to satisfy all dependencies the requested class has.

The advantage is that you can easily configure all dependencies in your bootstrapping logic and be able to change the behaviour of your application very easily.

For example when testing you start the application with an IMailerService implementation which writes the mails to a file and in production mode a real mail service is wired. This would not be possible if you newed up say a MailerService in your constructor instead of taking it as a parameter.

A good IoC container can handle much more, for you like lifetime management, singletons, scanning assemblies for Types you want to register and many more. We based our entire plugin system on Structure Map for example.

You may want to take a look at this blog article and its second part.