Using DI (Dependency Injection) & IoC (Inversion of Control) in MVVM

In this blog, I would like to give you an insight about the WPF and IoC to decouple views and ViewModels within MVVM
I would first like to shed some light on MVVM (Model/View/ViewModel).

 
MVVM is a more advanced and refined version of the MVC(Model/View/Controller). MVVM is a modern UI development platform for windows-based application that uses WPF (Windows Presentation Framework). The main function is to create web application in .NET. The definitive goal of MVVM is to achieve true separation of Model/ View / ViewModel. In this, the various elements of the project worked separately, are not dependent on each other and also not aware of each other, whereas it is not possible in WPF.

 
For your better understanding, consider the following example –
If you need to tie the ViewModel to View, you can use any one of the following steps:

After careful scrutiny, you will face some problem if you opt for the first approach. Although, you are creating a dynamic relationship between View and the ViewModel but this relationship is conflicting with the MVVM concept.
If you go by the second approach, you are adding a code which is generally not allowed in MVVM and this will not be suggested by any developer in WPF with MVVM.

 
However, if you use the third approach, be prepared to write lot of codes that will be hard to maintain for future reference purposes.

 
DI (Dependency Injection)
To counter this problem, use DI (dependency injection). In this approach, dependency injection will pass the instances of required objects into class via the constructor or through lookup classes (i.e. getters / setters of public properties)

Therefore, from above discussion, it is concluded that Constructor injection is a better way that will give right direction to achieve the MVVM concept. But again, it will be hard to maintain over a considerable period of time. The application will grow in future, as with time, the application will be needed to create services and disseminate it to the consumer. To avoid this repetition, the best approach is to use already available IoC containers.

 
IoC (Inversion of Control) Containers

There are some IOC containers available i.e. Unity from Microsoft, StructureMap (Open Source) and Castle Windsor (Open Source). These IoC containers take responsibility for managing instances of Views / ViewModel and perform the dependency injection automatically. The term inversion of control means that creating and keeping instances is not the responsibility of consumers anymore. That task is now delegated to an external container.

 
I would like to illustrate the same with an example of IoC container with StructureMap IoC container:
Situation: You need to install the StructureMap container in Visual Studio.
For this, you need to use Manage NuGet Packages in Visual Studio. After installation, you can use the reference of the StructureMap into the project. Following this, create a class which will initialize the IoC container using StructureMap.ObjectFactory . Post class creation you can define your type of projects like MyWindow and MyWindowViewModel. If you want to manage instances of an object automatically into an application, you must add them to the initialization method of this class.
In the App constructor, initialize the class in which you have already initialized the IoC container.
Finally, instead of creating the instance directly, make a call to container and request an instance from there.

Posted by-

Prabhat Rai 

Disclaimer: Developer’s Corner Section of ISHIR blog is contributed and maintained by independent developers. The content herein is not necessarily validated by ISHIR.