Passing context to nested regions

Topics: Prism v2 - WPF 3.5, Prism v2 - WPF 4
Sep 6, 2010 at 10:20 AM


I am attempting to use the child container feature of Unity to pass some context (a customer entity) to the view model for a region, and also for any view models for any nested regions.

In the snippet below I create the child container, register the customer with the child container and then resolve the view.

using (var childContainer = m_Container.CreateChildContainer())
	childContainer.RegisterInstance(customer.GetType(), customer);
	view = childContainer.Resolve<ITabItemView>(viewType.ToString());

This works fine with the view model on the parent view and the customer entity is passed into its constructor.  However, the customer entity is not passed into the view models for the nested child regions.

I understand that this is because the nested regions are resolved later on by the region manager and by this time the child container is out of scope.  I tried looking for a method on the scoped region manager I used to register any context, but couldn't find anything that could help. 

How do I pass this customer entity to any nested view models? 


Sep 8, 2010 at 8:21 AM

Can anyone help with this?


Sep 17, 2010 at 10:03 PM


I do not know your exact scenario, but it seems that it could be achieved with RegionContext, since it allows you to share an object context between different views, from the MSDN documentation:

There are a lot of scenarios where you might want to share contextual information between the view that is hosting a region and a view that is inside a region

Then you could pass that object from the viewHosted to the VM. There is an example about this in the ViewInjection Quickstart.

As for your approach, I’m not sure how ChildContainer could be affecting this scenario. If you consider that RegionContext doesn't fit in your scenario, could you send a repro solution?

Please let me know if this helps.

Fernando Antivero

Sep 20, 2010 at 8:18 AM


Thank you for replying.

I currently use the RegionContext approach, but I found that in each nested view I had to have the same piece of code that listened to when the region context changed;

var viewRegionContext = RegionContext.GetObservableContext(this);
viewRegionContext.PropertyChanged += this.ViewRegionContext_OnPropertyChangedEvent;


private void ViewRegionContext_OnPropertyChangedEvent(object sender, PropertyChangedEventArgs args)
	if (args.PropertyName == "Value")
		m_ViewModel.Customer = (Customer)RegionContext.GetObservableContext(this).Value;

While this approach does work, I wasn't keen on copying and pasting this code into each of my views - I though that injecting the customer directly into my view models would be a lot cleaner.

In our application I use the View Discovery approach as this seemed to be the most elegant.  I'm wondering if I should switch to using View Injection where I would have more control over when the nested views are actually created (so I can create them with the child container).  The thing I don't like about this approach is that now my application needs to know which views to create rather than 'just working' with View Discovery.




Sep 20, 2010 at 5:14 PM
Edited Sep 20, 2010 at 5:17 PM

Hi Matt,

Based on my understanding your scenario contains multiple views added in nested regions for showing one customer. Therefore, they have a View Model, which is injected with the same object model (customer) in all the cases (here is when you are copying and pasting the same code).

First of all, I completely agree with you that it does not make sense to repeat the same code lines. Your approach seems to be possible, but without having more context it is not possible to know why this could be failing. If you believe this is an issue mostly related to unity you could use the Unity forum as well.

On the other hand, I was thinking in some different approaches that might help in your scenario:

1) View Model Hierarchy. For more information download the latest drop of prism, so you could check the following section in the CHM:

  • MVVM Quickstart (new),  see the View/ViewModel Structure section.

You could see this implemented in MVVM Quickstart.

2) View Model locator for using the same ViewModel shared for all customer views:

Some of them could not fit in your scenario (a couple of modifications might be necessary but the ideas should guide you).

If you need more information when to use View Discovery vs View Injection, you could take a look at the following documentation section on MSDN:

  •  UI-Composition, see the When to Use View Discovery vs. View Injection section

I hope this helps,

Fernando Antivero

Sep 21, 2010 at 9:10 AM

Hi Fernando,

First of all thank you for continuing to help me with my problem.

I don't believe this is a problem with Unity as such, its just that Prism appears to defer creating the nested views until they are needed by which time my child container is out of scope.

I had a look at the latest drop of Prism as you suggested.  I can see how the MVVM Quick Start instantiates the child view models but I'm not sure this will work in my current scenario because in the Quick Start the parent view has hard-wired references to each of the child views.  Ideally I wanted to use regions throughout the application and let Prism manage the creation of views for me.

I also had a look at the ViewModel Locator which, although smart, I can't see how can help me in this situation.

Would you still be happy for me to send you a cut-down project which illustrates my scenario?  If so, where do I sent it to?





Sep 21, 2010 at 4:46 PM

Hi Matt,

I think you could upload this to the cloud, for example you could use skydrive. Then you could answer this thread for sharing the URL. So all the community could contribute as well.

Regarding to the quickstarts, take into account that they could provide guidance in a particular scenario, but if they do not fit exactly with your scenario, you could extend them.

ViewModel locator could help in your scenario to share an only one ViewModel (using some index) for all customer views, so it might be easy to inject the object model (customer) in an only one ViewModel. This way you could avoid using region context or other mechanisms for communication.

Fernando Antivero

Sep 29, 2010 at 10:47 AM

Hi Fernando,

I have uploaded a test project (VS2010) to;!114&authkey=QyT1Vs*4HJw%24

Hopefully the project is easy to understand.  It is basically a shell with a tab control.  Clicking either of the add buttons creates a new tab with parent view.  The parent view contains a child view.

What I am trying to do is pass a Customer entity to the view models for both the views (parent and child) when a tab is created.  Each view displays the ID of the customer to show whether it is working or not.

There are two 'add tab' buttons, one for the ideal way of implementing this which I am hoping to achieve, and the other for our current implementation which is far from ideal.


From this button I create a child unity container and register the Customer entity.  I then use the child container to create the parent view and add it to the tab.  Unity correctly passes the Customer entity into the constructor of the parent view, but does not pass it to the child view.  This is because I think that the unity child container is no longer in scope when the child view is created.


This button is similar to the Ideal button, but instead of using a child container, I instead loop round each region and pass the customer into the Context for the region.  The child view listens to the PropertyChanged event of the region context, and when it fires passes the context into the View Model.  You can see this in the code-behind for the child view, and this is the code that I have to cut/paste into all of my nested views for it to work.  I also then expose a method on the Parent view to pass in the customer manually.

Hope this makes sense



Sep 29, 2010 at 9:18 PM

Hi Matt,

Thanks for sharing this repro sample, I found that it is really clear. It seems that it is not supported to use child containers when discovering views using View Discovery in Prism. The View Discovery technique is using the main container of the application for injecting dependencies.

Even if you use the RegisterViewWithRegion method overload which supports indicating a delegate, it does not work as you expected.

In this type of scenarios, the recommended approach is to use View Injection which is the other technique for UI-Composition. From the MSDN documentation (see When to Use View Discovery vs. View Injection section):

You can use view injection if you need one of the following:

  • Explicit or programmatic control over when a view is created and displayed, or when you need to remove a view from a region, for example, as a result of application logic.


Therefore, as you need programmatic control, you could use View Injection with child containers. So your code might look like the following:

private void btnAddTabIdeal_Click(object sender, RoutedEventArgs e)
    IRegion mainTabRegion = m_RegionManager.Regions[RegionNames.TabControlRegion];            

    m_ID += 1;
    var customer = new Customer() { ID = m_ID };           

    using (var childContainer = m_Container.CreateChildContainer())
        childContainer.RegisterInstance(customer.GetType(), customer);                                
        var view = childContainer.Resolve<Parent_Ideal_View>();
        var childView = childContainer.Resolve<Child_Ideal_View>();
        var regionManager = mainTabRegion.Add(view, customer.ID.ToString(), true);
        var childRegion = regionManager.Regions[RegionNames.Child_Ideal_Region];

If you would like to continue using View Discovery, you can avoid using child containers, since I could not find a reason of the need for creating a child container in this scenario.

I hope this help.

Fernando Antivero


Sep 30, 2010 at 8:11 AM

Hi Fernando,

Thank you for your quick response.  Your answer makes sense and to be honest was something that I was starting to suspect would be the only solution.

Our application uses View Discovery throughout and I feel that this is one of the great benefits of Prism, especially as we use the same regions in different parts of our application.

At this point I'm not sure whether I want to lose the niceness of View Discovery for the benefit of removing some duplicated code.

I guess that I might have to take a pragmatic viewpoint and keep with View Discovery for now and see how it goes.

Thanks for your help



Jan 15, 2013 at 12:52 PM

I have exactly the same requirement - I want modules to be able to use a view-discovery like mechanism to specify what types should be used when creating views for a given region and we also want certain regions (or region managers) to use child unity containers to allow us to inject specific dependencies for those scoped regions.  View injection won't work as at the point where the module is initialised these regions have not yet been created and using the region context is cumbersome in comparison - to start with it requires that each region be individually tagged with the appropriate unity container.

My solution was to extend Prism and replace the view discovery mechanism with one that searches the logical tree for a scoped injection container which is then used to resolve the view (rather than using the globally scoped injection container). I've hosted the source code here

Its not perfect but it seems to work well enough.