Presenter Class Dependency on IUnityContainer

Apr 2, 2008 at 4:53 PM
I thought this code was pretty interesting as I had never thought about registering the container in itself:

private void InitializeContainer()
    container = new UnityContainer();

It then comes into play, for example, in the PositionModule Initialize Code:

public void Initialize()
    PositionSummaryPresenter presenter = _container.Resolve<PositionSummaryPresenter>();

because the PositionSummaryPresenter has a depedendency on IUnityContainer in its constructor:

public PositionSummaryPresenter(
             IPositionSummaryView view
            , IAccountPositionService accountPositionService
            , IMarketFeedService marketFeedSvc, INewsFeedService newsFeedSvc
            , IMarketHistoryService marketHistorySvc
            , IUnityContainer container
            , INewsService newsSvc
            , IRegionManagerService regionManagerService)

which then uses the container in ShowViews() to create the ITrendLinePresenter.

public void ShowViews()
    trendLinePresenter = Container.Resolve<ITrendLinePresenter>();
    // ...

Is it a good practice to have a Presenter Class, in this case, dependent on the container? I thought it was a pretty slick idea, but am not sure if this is an acceptable practice, code smell, or temporary solution until you get things worked out.


Apr 3, 2008 at 11:57 AM
It is not only a good practice but in many cases, mandatory as some dependencies, you'll want to lazy load. It wouldn't make sens to create your application entire graph upfront.

I usually adapt IUnityContainer into an IServiceLocator or IDependencyLookup as it decouples Resolve from Register, the same way you split a Reader and a Writer.
Apr 3, 2008 at 2:12 PM
Edited Apr 3, 2008 at 2:12 PM
I typically create a static ServiceLocator Class and just call it when necessary from within the class, such as:


I hadn't thought about registering an IServiceLocator with the container and then passing it in via the constructor.

I think I like that better than making a static call from within the class.

Thanks for the perspective, Francois.


Apr 3, 2008 at 4:19 PM
One of the benefits to utilizing an instance-based Service Locator is that you can infer scope. With a static locator, it's going to use the same mechanism to resolve the services each time unless you explicitly pass in a scope value of some kind.

Apr 4, 2008 at 5:27 PM
Good point, Derek.
Apr 12, 2008 at 2:25 AM
In "Prism" we are encouraging explicit use of your specific container. If you chose to use Unity in your app, then you are happy with Unity semantics, same with Windsor. Having an abstraction for resolving services is forcing you into using the "One interface to unite them all", and is self-defeating. We do have the IPrismContainer abstraction, but this is only for low-level core services.

You can easily take the code in the RI and change it to use Windsor for example. We are not taking any hard dependencies in the design on any specific container.

Apr 16, 2008 at 11:05 AM
Have you ever thought about inheriting any Presenter from UnityContainer instead of injecting container's instance into it so Presenters might look like child containers chain?
Apr 20, 2008 at 10:02 PM

A presenter is NOT a container. There is not such thing as an inheritance relationship between those two concepts.
May 8, 2008 at 7:40 AM

The reason why we did this registering the container in the container is because there are places where you need to imperatively register and resolve. As an example in a module, you register views and presenters. We don't force you to do this in config, as doing it in the module allows it to happen only in the cases where the module loads. Also having it in code is more explicit and easier to debug (in some cases). Often you'll see the view get resolved right after it is registered. We do this so that the view can have it's dependencies injected by the container, leveraging DI rather than manually injecting.