Why use a dependency injection container?

Question

I finished Karl Shiffet's 'InTheBox' WPF Training and found it to be a great resource for learning WPF. One thing that caused this is the use of Dependency Injection and the Unity Container. Here is the code section that raised some questions for me:

public partial class App : Application { protected override void OnStartup(StartupEventArgs e) { IUnityContainer container = new UnityContainer(); container.RegisterType<IDialogService, ModalDialogService>( new ContainerControlledLifetimeManager()); container.RegisterType<IEventRepository, EventRepository>( new ContainerControlledLifetimeManager()); MainWindow window = container.Resolve<MainWindow>(); window.DataContext = container.Resolve<MainWindowViewModel>(); window.Show(); } } 

Dependencies are registered in the UnityContainer and then introduced by the UnityContainer in the MainWindowViewModel. My question is: why use a container? Why not just use the following code snippet, which provides the same thing as for dependency injection:

 protected override void OnStartup(StartupEventArgs e) { IDialogService dialogService = new ModalDialogService(); IEventRepository eventRepository = new EventRepository(); MainWindow window = new MainWindow(); window.DataContext = new MainWindowViewModel(eventRepository, dialogService); window.Show(); } 

I am still injecting dependencies into the constructor from the root of the composition, so I don’t see the use of UnityContainer in this.

I appreciate that it obviously exists for some reason, but can anyone explain if it adds anything in this situation? Also, is there another situation where using a container like this is really hassle-free?

Answer 1

Using a DI container in a simple case like this is actually not very much for you. This starts to make more sense when things get more complicated, and also minimizes the effect of dependency changes.

Say, for example, you have an ILoggingService service that all your dependencies are now using. When using a DI container such as Unity, you should add only one line of code.

  protected override void OnStartup(StartupEventArgs e) { IUnityContainer container = new UnityContainer(); container.RegisterType<IDialogService, ModalDialogService>(); container.RegisterType<IEventRepository, EventRepository>(); container.RegisterType<ILoggingService, LoggingService>(); // added MainWindow window = container.Resolve<MainWindow>(); window.DataContext = container.Resolve<MainWindowViewModel>(); window.Show(); } 

When doing this, you must add one line of code and change 3 lines of code.

  protected override void OnStartup(StartupEventArgs e) { ILoggingService loggingService = new LoggingService(); // added IDialogService dialogService = new ModalDialogService(loggingService); // modified IEventRepository eventRepository = new EventRepository(loggingService); // modified MainWindow window = new MainWindow(); window.DataContext = new MainWindowViewModel(eventRepository, dialogService, loggingService); // modified window.Show(); } 

When using more advanced containers that can scan types for registration, you may not have to change the code at the root of your composition. Here is an example of using AutoFac.

  protected override void OnStartup(StartupEventArgs e) { var builder = new ContainerBuilder(); var assembly = Assembly.GetExecutingAssembly(); builder.RegisterAssemblyTypes(assembly) .AsSelf() .AsImplementedInterfaces(); var container = builder.Build(); MainWindow window = container.Resolve<MainWindow>(); window.DataContext = container.Resolve<MainWindowViewModel>(); window.Show(); } 

Answer 2

You make a good moment. Your second example uses what Mark Semann may call the “Poor Man.” This is still DI, but you do it yourself.

IoC containers come to life when you start managing the injections of many different types and functions, such as lifestyle management and type registration by agreement, become huge employers.

For small tasks with minimal dependency management, as you suggested, they are likely to overdo it.

I would highly recommend the Seemann book and blog if you want to know more. IMHO, he explains this topic better than anyone.