0

We're wondering what the best practise for registering types in a IoC-Container is.

What would be arguments for and against the following principles:

Principle 1: Only one Assembly my.project.DependencyInjection

  • Seperate assembly for dependency injection
  • One class (f.e. UnityConfig.cs) where all types of the whole solution are registered
  • my.project.DependencyInjection references alot of projects to register their types

Principle 2: A IoC container configuration class per executing assembly

  • Every executing assembly has their own UnityConfig.cs file
  • Only the needed types of this assembly are registered in the respective UnityConfig.cs file

What's your stance in this?

Thanks in advance for your opinions and arguments

xeraphim
  • 4,375
  • 9
  • 54
  • 102
  • See the concept of the [Composition Root](http://blog.ploeh.dk/2011/07/28/CompositionRoot/). – Steven Nov 02 '17 at 14:55

1 Answers1

1

my Answer 

Principle 2: A IoC container configuration class per executing assembly

Every executing assembly has their own UnityConfig.cs file
Only the needed types of this assembly are registered in the respective UnityConfig.cs file

The reason being, Dependencies are or should be injected at the run-time, so the responsibility of configuring what to inject should live at the top level component/executable, ie in mvc/web-api/wcf/exe.

Also with this approach each project can differ in DI tool, config etc etc.

Preet Singh
  • 1,791
  • 13
  • 16