R – IoC and User Interfaces

dependency-injectioninversion-of-controlstawpf

I'm trying to wrap my head around the best way to use IoC within my application for dependency injection, however I have a little issue.

I am using a loose implementation of the MVP pattern with a WPF app. Essentially, a presenter class is instantiated, and a view and task (e.g. IEmployeeView and IEmployeeTask for EmployeePresenter) are injected into the presenter.

I would like to use an IoC container (I'm trying out Unity, though I guess this would also happen with others such as ninject or Structure Map) instead of manually injecting these instances, however if the presenter is created (or resolved from an IoC container) on an async delegate call, or an event thread (e.g. not STA threaded) then creating a new instance of a WPF window throws the following exception:

The current build operation (build key
Build Key[namespace.Window1, null])
failed: The calling thread must be
STA, because many UI components
require this.

Now, I know that new window instances etc need to be STA, however is it possible to use an IoC Container to do the dependency injection even when the UI must be created on an STA thread?

From looking at this problem it would seem that the class/type being resolved is instantiated at the resolve time, not when its registered…

Best Answer

I would say to use a Factory to create the Presenter objects; that way, you can create your generic instances of Presenters from within your PresenterFactory in an STA thread, and then simply pass them out when required.

Related Solutions

Wpf – Is Dependency Injection possible with a WPF application

It's actually very easy to do. We have examples of this in Prism as jedidja mentioned. You can either have the ViewModel get injected with the View or the View get injected with the ViewModel. In the Prism StockTraderRI, you will see that we inject the View into the ViewModel. Essentially, what happens is that the View (and View interface) has a Model property. That property is implemented in the code-behind to set the DataContext to the value, for example: this.DataContext = value;. In the constructor of the ViewModel, the View gets injected. It then sets View.Model = this; which will pass itself as the DataContext.

You can also easily do the reverse and have the ViewModel injected into the View. I actually prefer this because it means that the ViewModel no longer has any back reference to the view at all. This means when unit-testing the ViewModel, you don't have a view to even Mock. Additionally, it makes the code cleaner, in that in the constructor of the View, it simply sets the DataContext to the ViewModel that was injected.

I talk a bit more about this in the video recording of the Separated Presentation Patterns talk that Jeremy Miller and I gave at Kaizenconf. The first part of which can be found here https://vimeo.com/2189854.

R – Why not pass your IoC container around

To abstract away the instantiation of another component, you can use the Factory pattern:

public interface IComponentBFactory
{
    IComponentB CreateComponentB();
}

public class ComponentA : IComponentA
{
    private IComponentBFactory _componentBFactory;

    public ComponentA(IComponentBFactory componentBFactory)
    {
        _componentBFactory = componentBFactory;
    }

    public void Foo()
    {
        var componentB = _componentBFactory.CreateComponentB();

        ...
    }
}

Then the implementation can be registered with the IoC container.

A container is one way of assembling an object graph, but it certainly isn't the only way. It is an implementation detail. Keeping the objects free of this knowledge decouples them from infrastructure concerns. It also keeps them from having to know which version of a dependency to resolve.

Related Topic