Replacing ServiceLocator with DependencyInjection when implementing modal dialogs in MVVM WPF application

Question

I am writing my first WPF application and I would like to ask you for help with a problem that I encountered.

I am trying to follow the MVVM pattern and I came to a point where I need to implement modal dialogs. I googled/read on the topic for some time and I was able to settle on a solution. However, when refactoring I encountered a dilemma that concerns using a DI (constructor injection) as a replacement of a service locator.

I am going to be referencing these: http://pastebin.com/S6xNjtWW.

I really like the approach of Roboblob:

First: He creates an abstraction of a modal dialog (interface). I named the interface IModalDialog and this is how it looks like:

public interface IModalDialog
{
    bool? DialogResult { get; set; }
    object DataContext { get; set; }

    void Show();
    bool? ShowDialog();
    void Close();        

    event EventHandler Closed;
}

Second: An abstraction of modal dialog service:

public interface IModalDialogService
{       
    void ShowDialog<TDialogViewModel>(IModalDialog view, TDialogViewModel viewModel, Action<TDialogViewModel> onDialogClose) where TDialogViewModel : class;        
    void ShowDialog<TDialogViewModel>(IModalDialog view, TDialogViewModel viewModel) where TDialogViewModel : class;        
}

Third: The concrete implementation of IModalDialogService:

    public class ModalDialogService : IModalDialogService
    {
    public void ShowDialog<TDialogViewModel>(IModalDialog view, TDialogViewModel viewModel, Action<TDialogViewModel> onDialogClose) where TDialogViewModel : class
    {
        // set datacontext
        if (viewModel != null)
        {
            view.DataContext = viewModel;
        }
        ((System.Windows.Window)view).Owner = System.Windows.Application.Current.MainWindow;
        // register 
        if (onDialogClose != null)
        {
            view.Closed += (sender, e) => onDialogClose(viewModel);
        }
        view.ShowDialog();
    }


    public void ShowDialog<TDialogViewModel>(IModalDialog view, TDialogViewModel viewModel) where TDialogViewModel : class
    {
        this.ShowDialog(view, viewModel, null);
    }

Fourth: There are more implementations of IModalDialog. Each is a Window-derived class that implements IModalDialog.

---

Before I ask the question (describe the problem), I need to explain this beforehand:

Let's say that I have some more services, like for example IMessageBoxService. Then I need to declare these dependencies in the constructor of MainWindowViewModel:

public MainWindowViewModel(IModalDialogService a,                               
                           IMessageBoxService b,
                           ...)

so that I can inject them (either by hand or using IOC container like Unity, etc.).

In order to be able to use the modal dialog service there is one missing piece of puzzle - the ability to resolve a concrete implementation of IModalDialog based on some key.

Roboblob in his article solves this last piece of puzzle using a ServiceLocator pattern:

public class Bootstrapper
{
public static void InitializeIoc()
  {
    SimpleServiceLocator.SetServiceLocatorProvider(new UnityServiceLocator());
    SimpleServiceLocator.Instance.Register<IModalDialogService, ModalDialogService>();
    SimpleServiceLocator.Instance.Register<IMessageBoxService, MessageBoxService>();
  ...    
    SimpleServiceLocator.Instance.Register<IModalWindow, EditUserModalDialogView>(Constants.EditUserModalDialog);
  }

}

so he inside his MainWindowViewModel simply calls the static classes Get and resolves a concrete implementation of IModalDialog window based on a key.

Even Josh Smith uses a similar approach in his article but in comments he says that (DI - constructor injection) is a valid option.

The referenced StackOverflow answer also describes a similar WindowViewLoaderService that could be modified and use.

---

So the question is - what would be the best way to replace the ServiceLocator (which resolves the concrete implementations of IModalDialog) with a dependency injection?

My train of thoughts was:

1. One possibility is (due to the project not being very big/developed by me only) to just create a new service (e.g. called IModalDialogResolver) that would create and return new instances of concrete implementations of IModalDialog. Have all the services injected by hand.

2. Then I thought about an IOC container (Unity). I have no experience with it. I thought that maybe I don't have to write the IModalDialogResolver as I could register the different implementations of IModalDialog with Unity container => but then how do I use the container inside MainWindowViewModel? I cannot pass the reference to the constructor as that would be a step back to ServiceLocation.
   So then I thought that maybe I can use one unity container in the bootstrapper to resolve all the services and use another one internally inside the IModalDialogResolver. But I don't know whether this is a good idea regarding the recommended usage of Unity. I really know too little to judge this. But something tells me that this is not a good idea as it creates a hidden dependency on the container + if the container is a singleton that would be equivalent to just passing the reference into the constructor.

To maybe better explain the mental block that I have: I would like to use an IOC container (e.g. Unity) to have the interfaces constructed and injected by it. But then I cannot just put IModalDialog as a parameter inside a constructor. So probably I really need to wrap this inside a service and implement myself - but then (provided that Unity can do this out of the box) it doesn't make sense to have Unity there in the first place if i cannot use it.

I know one of the alternatives is to put this one service into a base class, but for the sake of argument, let's not consider this. I really would like to learn about the right way to have this solved using dependency injection.

Answer 1

It's perfectly valid and expected for you to access the IoC container within your composition root.

In fact this should be the only location where you container is accessed.

In the example you've given, that's all that is happening - the concrete implementations are being registered in the container within the composition root.

So to answer your question, you don't need to replace the use of the service locator pattern here, as it's just a mechanism for registering the types in the composition root, which is perfectly valid.

If you wish to instantiate the modal dialog service based on some run time conditions, then you should inject a model dialog service factory instead (again an abstraction with an implementation registered in your container), and then the factory would have a method to create the model dialog service and this factory method would take the run time parameters required.

Your factory could then new up the appropriate model dialog service appropriately based on the run time parameters. Alternatively, it could also resolve the appropriate model dialog service from the container, which would obviously require the factory to have a reference to the container.

Most containers support automated factory types, so that you only need to define the interface for the factory, and the container will automatically implement the factory using conventions. Castle.Windsor for example has the Typed Factory Facility and Unity has some equivalents.