Not understanding where to create IoC Containers in system architecture

Question

Hi,

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

The module distinction and the "scopes" defined by the modules exist mostly at compile-time. In the run-time it's all one big mess ;) This is used by most IOC containers and they don't really care about where they are located. The IoC container for a web-app will typically be created at the outermost level (very close to the web-container itself).

Answer 2

It's true that you could create it anywhere, but I'd introduce an extra layer, let's call it 3.5.

Your current 3 would be where your IoC resides for Data Access - this would become a wrapper for your actual DAL. Based on your config, 3 would create either a mock repository or a concrete one.

So 2 still references 3, but it's just an interface to the actual DAL which is configured through your IoC framework.

Alternatively, you could roll your own 'el-cheapo' IoC - change your Big Ugly Singleton to a Static Gateway - http://stackoverflow.com/questions/277438/abstracting-ioc-container-behind-a-singleton-doing-it-wrong

Answer 3

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

Answer 4

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 5

Top level is a way to go (UI, as Rinat said).

Now as for references, simplest way is just to go over all assemblies in the current folder and use some convention to get the services out. Attributes work fine, putting registrar classes in each assembly works fine, whatever suits you. The code for extracting everything should probably be in a separate assembly, unless your IoC framework already does that.