Manually Implement IoC Using a Windows Service

Question

I am new to IoC and therefore follow the examples provided by Jeffrey Palermo in his posts at http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ and posted in his book here https://github.com / jeffreypalermo / mvc2inaction / tree / master / manuscript / Chapter23

Most importantly, I do not use a pre-packaged IoC container, mainly because I want to understand all the moving parts.

However, I am creating a Windows service, not an ASP.NET MVC webapp, so I am a bit bogged down in the start part. In particular, in web.config, it registers the implementation of IHttpModule INSIDE in the infrastructure project as a launch module, and then uses the post-build event to copy the necessary DLLs to the website directory in order to manage the direct dependency in the web project itself.

I don’t think I have this type of luxury in a true Windows service, since I can achieve something like this, should I have a small startup project that has dependencies on both the infrastructure and the Core, or is there another method to bypass Windows compilation time limits?

Thanks in advance.

Answer 1

Based on the tags of this question (C #), I assume that you will implement the Windows service because of ServiceBase . If so, the OnStart method will be your composition root - here you create the graph of the application object. After you make a graph of objects, the composition will end, and the graph of the composed object will take over.

In OnStop, you can turn off the object graph again.

There is nothing stopping you from implementing the various components of the graph of allowed objects in separate assemblies. This is what I will do.

Answer 2

I think you missed an understanding of the structure of IoC.

To answer your question

but is the link referencing the dependency?

Yes, but it is on a different level. IoC are dependencies between classes. Instead of using new Something() in your class, you provide a constructor that requires all dependent interfaces. Thus, the class does not have control, the implementation of which is passed to it. This is an inversion of control. An IoC container is just an aid to helping you manage your dependencies in a pleasant way.

Say you have an ICustomerNotificationService interface with an implementation, for example

 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 indicates which specific implementations to take and tries to satisfy all the dependencies that the class requested.

The advantage is that you can easily configure all the dependencies in your boot logic and easily change the behavior of your application.

For example, during testing, you run an application with the implementation of IMailerService , which writes letters to a file and connects a real mail service in production mode. This would not be possible if you introduced a new constructor instead of as a constructor instead of MailerService .

A good IoC container can handle much more for you, like life cycle management, single player games, scan assemblies for the types you want to register, and much more. We based our entire plugin system on a Structural Map , for example.

You can take a look at this blog article and its second part .