Not understanding where to create IoC Containers in system architecture

Question

Say I have the following 4 .net assemblies:

1. Winforms UI
2. Business Logic
3. SQL Server Data Access (implementing an IRepository)
4. Common Interfaces (definition of IRepository etc.)

My business logic (2) makes calls to the data access layer (3) through IRepository (defined in 4) using constructor dependency injection. However when I ceate a business object I need to pass in an actual repository. I do this by having a singleton class in my business logic layer return the currently in use concrete object implementing IRepository. I am coming to the conclusion that this is a bad thing, as my business logic layer now has to reference 3 as well as 4.

I think I need a IoC Container but the question is where I create/put it as it seems that wherever I create this (1 - UI)? will also need to hold a reference to 3 (SQL Server Data Access). Am I not just moving the problem rather than achieving actual decoupling?

Do I create the IoC Container in the UI. Or expose it through another new assembly.

(I'm using C#, .net 3.5 and AutoFac)

Thanks.

Answer 1

IoC container generally should be created in the host project (application entry point). For the Windows.Forms application that's the exe project.

Generally in simple solutions (under 10 projects), only a host project should have a reference to IoC library.

PS: Structuring .NET Applications with Autofac IoC

Answer 2

When registering components there are several possibilities:

1. Registration in code:

   • directly
     Problem: you have to reference everything ( you are here)
   • indirectly
     Problem : to find out what has to be registered
     Solution:
     1. use attributes
     2. use marker interface as IService
     3. use conventions (see StructureMap)

2. Registration with configuration file:

   • let the container do everything
   • read the file yourself