Injecting multiple ICommand implementations with the Microsoft Unity container
Hello, and welcome to my second article on Dependency Injection and IoC with the Microsoft Unity Framework. In my last post Dependency Injection and Inversion of Control with the Microsoft Unity Container I discussed the importance of coding to an interface and not a concrete implementation. I also introduced the idea of dependencies, and dependency injection using Unity.
As I've been working a lot lately in XAML using the MVVM (Model-View-ViewModel) Pattern, I find myself implementing a lot of ICommand classes. The ICommand interface is very simple, with a method for execution, a method to check if the command can execute, and an event handler to specify the state of the command execution. The interface is very useful because of the way that XAML can bind to these commands to perform actions on button click's and other user interface actions.
Dependency Injection with multiple ICommand implementations
So I had a lot of implementations of the ICommand interface that were used to call on the service layer of my application to complete application tasks. My past experience up until this point never required for me to register one type with multiple interfaces. Luckily, I found it that Unity has a nice way to handle this issue.
So when I setup my container, I register the commands like this
_container.RegisterType<ICommand, LoadQuizesCommand>("LoadQuizes");
_container.RegisterType<ICommand, CreateQuizCommand>("CreateQuiz");
_container.RegisterType<IQuizService, QuizService>();
_container.RegisterType<IMainQuizMenuViewModel, MainQuizMenuViewModel>();
Then here is the ViewModel where the dependencies are injected in the constructor.
using Domain.QuizIt;
using Microsoft.Practices.Unity;
using QuizIt.ViewModels.Interfaces;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Input;
using Service.QuizIt.Interfaces;
namespace QuizIt.ViewModels
{
/// <summary>
/// This represents the ViewModel that is bound to the Main Quiz user interface.
/// </summary>
public class MainQuizMenuViewModel : IMainQuizMenuViewModel
{
#region "public properties"
public ICommand LoadQuizesCommand { get; set; }
public ICommand CreateQuizCommand { get; set; }
public IQuizService QuizServiceManager { get; set; }
public List<Quiz> Quizes { get; set; }
public string QuizName { get; set; }
public string QuizDescription { get; set; }
#endregion
#region "constructors"
public MainQuizMenuViewModel([Dependency("LoadQuizes")]ICommand loadQuizesCommand,
[Dependency("CreateQuiz")]ICommand createQuizCommand, [Dependency]IQuizService quizServiceManager)
{
this.LoadQuizesCommand = loadQuizesCommand;
this.CreateQuizCommand = createQuizCommand;
this.QuizServiceManager = quizServiceManager;
}
#endregion
}
}
Notice how I specify the same names in the Dependency attributes in the constructors as I did when registering the types. This way I can specify the command by name and resolve different implementations for multiple ICommand interfaces.
I hope you enjoyed reading this post. Please feel free to comment if you have any tricks of your own with injecting multiple interfaces.

Design for Reusability
A well designed application should promote code reuse whenever possible. Code reuse can save you time and money by allowing you to use components from previous applications to solve common problems in new projects. The task of managing dependencies is one of the many concerns a developer faces when designing for reusability. Dependencies are any classes that a particular class must directly instantiate and use in order to accomplish a task. As a rule of thumb, it's good object oriented programming practice to code to an interface rather than a concrete implementation. This will make your code flexible and built for change.
An example of a dependency
You've been tasked to write a console application. The application requires that the user authenticates before using any of the features and there is a requirement that all successfully log-ins are logged to a text file. Here is the code for the example.
TextLogger.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace UnityExample
{
public class TextLogger
{
public void LogMessage(string message)
{
//Code to write the message to a text file....
Console.WriteLine(string.Format("Logging the message to a text file: {0} ", message));
}
}
}
AuthenticationService.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace UnityExample
{
public class AuthenticationService
{
public AuthenticationService()
{
}
internal void Authenticate(string userName, string password)
{
//Authentication logic goes here
TextLogger logger = new TextLogger();
logger.LogMessage("Login was successful");
}
}
}
Program.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace UnityExample
{
class Program
{
static void Main(string[] args)
{
AuthenticationService authenticationService = new AuthenticationService();
authenticationService.Authenticate();
}
}
}
This is a basic example for demonstration purposes only. Now, as you can see in the AuthenticationService Authenticate method we are instantiating an instance of the TextLogger class. So now a few weeks pass by and the customer wants you to log to a database instead of a text file. So you create a new class.
DBLogger.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace UnityExample
{
public class DBLogger
{
public void LogMessage(string message)
{
//Code to write the message to a database....
Console.WriteLine(string.Format("Logging the message to a database: {0} ", message));
}
}
}
The AuthenticationService was dependent on the TextLogger and is now dependent on the DBLogger class. The current design requires us to change the AuthenticationService any time the customer requests a new type of logger. The same holds true for any unit tests that we write that uses a Logger class. As you can see the design promotes tight coupling because we are coding to a concrete implementation which is not very flexible.
Introducing an interface
As we can see, both logger classes have one method called LogMessage. They share the same interface. This is a perfect example of an instance in which we should code to an interface. So we start by creating an interface that matches the two logging classes.
ILogger.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace UnityExample
{
public interface ILogger
{
void LogMessage(string message);
}
}
Now we could simply change the logger declaration in the AuthenticationService and be done with it, however, there are still some optimizations that can be achieved. For instance, currently the Logger declaration is a local variable inside of the Authenticate method. Imagine were to inject the ILogger as a parameter of the AuthenticationService constructor. This is a much more flexible design because the AuthenticationService only has knowledge of an ILogger. Since the implementation is injected via the constructor, the class is no longer tied to any one specific implementation.
Here is the updated AuthenticationService.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace UnityExample
{
public class AuthenticationService
{
//the logger is now a class field
private ILogger logger;
public AuthenticationService(ILogger implementation)
{
//The implementation is injected via the constructor
logger = implementation;
}
internal void Authenticate(string userName, string password)
{
//Authentication logic goes here
logger.LogMessage("Login was successful");
}
}
}
DBLogger.cs updated
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace UnityExample
{
public class DBLogger : ILogger
{
public void LogMessage(string message)
{
//Code to write the message to a database....
Console.WriteLine(string.Format("Logging the message to a database: {0} ", message));
}
}
}
The Unity Container
The Unity container allows us to use code (or a configuration file) to associate an interface with a class. This is typically done during your application start up or the set up of your unit tests. You register your interface and class mappings. Then later when it's time to instantiate an instance of your objects, you ask the container to resolve an instance of the object that you need. The Unity container will perform an internal look up and it will resolve any dependencies that your object's constructor depends on.
I prefer to register my interface/class mappings in a class that I call a module. When my application starts I load all modules to prepare the container to resolve all of the objects that I will need. This abstraction allows you to easily switch an interfaces implementation at run time providing a high level of flexibility to your code. Here is a brief example of how to use the Unity container. You will need to download the Unity assemblies from nuget or from the Microsoft patterns and practices Unity Application block site.http://unity.codeplex.com/
LoggingModule.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.Practices.Unity;
namespace UnityExample
{
public class LoggingModule
{
IUnityContainer _iocContainer;
public LoggingModule(IUnityContainer container)
{
_iocContainer = container;
}
public void Init()
{
//Add any logic here to look in a config file, check a property
//or any other condition to decide which implementation is registered.
//register the database logger to the ILogger interface
_iocContainer.RegisterType(typeof(ILogger), typeof(DBLogger));
}
}
}
Updated Program.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.Practices.Unity;
namespace UnityExample
{
class Program
{
private static IUnityContainer _iocContainer;
static void Main(string[] args)
{
//create our container
_iocContainer = new UnityContainer();
InitializeModules();
//the container knows how to create an AuthenticationService object
//as well as what type of ILogger it takes because we registered
//the required class in the loggerModule.
var authenticationService = _iocContainer.Resolve<AuthenticationService>();
authenticationService.Authenticate("username", "password");
Console.WriteLine("press any key");
Console.ReadKey();
}
private static void InitializeModules()
{
//pass the container to the module
//so when we register the types we can resolve them
var loggingModule = new LoggingModule(_iocContainer);
loggingModule.Init();
}
}
}
This is a very basic introduction to Unity but you I hope that you can see the possibilities when you program to interfaces and let the container take control of object creation. You could extend this example to create a ModuleInitializer class that takes the modules that need to be initialized.
The bottom line is
Program to interfaces
Inject dependencies via the constructor
Register your dependency interfaces to the desired class in the unity container. You can use a module approach if you so choose.
As long as your interfaces are mapped to classes in your container, the container can resolve any dependencies that your object requires when instantiated.
Download the source
UnityExample.zip (723.64 kb)
Happy coding!

About the author

My name is Buddy James. I'm a Microsoft Certified Solutions Developer from the Nashville, TN area. I'm a Software Engineer, an author, a blogger (http://www.refactorthis.net), a mentor, a thought leader, a technologist, a data scientist, and a husband. I enjoy working with design patterns, data mining, c#, WPF, Silverlight, WinRT, XAML, ASP.NET, python, CouchDB, RavenDB, Hadoop, Android(MonoDroid), iOS (MonoTouch), and Machine Learning. I love technology and I love to develop software, collect data, analyze the data, and learn from the data. When I'm not coding, I'm determined to make a difference in the world by using data and machine learning techniques. (follow me at @budbjames).