On creating multiple window WPF Prism applications

Topics: Prism v4 - WPF 4
Jun 25, 2013 at 2:52 PM
Edited Jun 25, 2013 at 9:37 PM
As it seems, Prism was designed as a single-windowed navigation-based platform in which the shell contains static regions and it navigates between views by changing the regions content.
I had to design a project that would contain multiple potentially parallel windows. I decided to keep using the shell as a master page, and to add windows as regions using scoped regions.
The problem was the syntactical complexity of adding scoped region managers to views, in regions, again defined in views with some different scoped region managers - all of it in code and for each window.

My solution, which I wish to share here, was basically to define a window as a XDom, for example, in the pattern :
   <View view_name="...", view_contract_name="...",  ...>
       <Region region_name="...", ...>
             <View view_name="...", view_contract_name="...",  .../>
             <View view_name="...", view_contract_name="...",  ...> 
                   <Region region_name="...", ...>
                        <View view_name="...", view_contract_name="...",  .../>
keeping it as a string in a dedicated exported class ( I use DI with MEF), and using a dedicated controller which uses a recursive procedure with Linq to XML to reproduce the windows when needed.
The controller would be defined just once, and as you see, that leaves us with a XAML-like approach in which first we write the "XAML" (actually the xml) for the composition of parts and then the real XAML for every part in turn, in line with the overall approach.

What do you think of that ?
Jun 25, 2013 at 6:39 PM

This seems to be an interesting approach.

Thanks for sharing it as it might be useful for other users of the community.


Federico Martinez
Jun 25, 2013 at 6:58 PM
Edited Jun 25, 2013 at 7:01 PM
Actually, there may be more to it. We can add attributes or attribute values, for example, to the XDom instances. I use commands which send events to the controller through the event aggregator. Now, the event argument is an object - we can add there some attribute values for the XDom (while activating the command in some viewmodel) - and add some custom "triggers" in the XDom class beforehand to be interpreted by the controller in connection with the attribute values while creating the windows, and we get conditional Composition.
I use XDoms instead of real XAML because I want to use Composition and Prism regions/views. It may be possible to implement Composition in XAML, though... ;-)
Jun 25, 2013 at 9:42 PM
Edited Jun 26, 2013 at 6:47 AM
It seems it is indeed possible to do all the forementioned stuff by using only plain XAML, by using value converters.

One possible way to do it can be based on the following two issues:
  1. Value converters act as a kind of delegates from the XAML to their class implementations functions. Therefore, supposing that we want to declare a certain control in our window's XAML as a region, we can assign a region name, for example, to the tag property using a value converter, and the control itself as the object parameter. The value converter, in turn, in code, would do all the regular stuff of creating a region manager and so on, and would perhaps return ... ;-) the original string (as the region name). Alternatively, we could declare our own custom region property.
  2. XAML can contain elements without UI. We can use them as the control children to designate the other components and would declare them as above - using (different) value convertors.
The window XAML would be kept in a dedicated dll which in turn would be exported using a contract (we're using MEF).

It may all seem quite complex, but once the pattern is laid down , we can continue just by using XAML.

I will elaborate on it in a different post - on using DI and MEF and PRISM with XAML. I hope I am not mistaken - but if I am ,please correct me.
Jun 29, 2013 at 11:38 AM
I was told that the usage of MEF's Input and Output abilities renders Prism's regions superfluous.
Can someone comment on it please ?
Jul 1, 2013 at 7:06 PM

I might not be understanding what you meant by "Input and Output abilities," but as far as I know, MEF and Prism's Regions address different requirements:

  • MEF allows you to register and compose parts which are simply classes that define dependencies and are registered in the container to be available to other parts. Basically, it works as a dependency injection container.
  • Prism's Regions provide a mechanism to compose the IU by decoupling the different views in your application through the Regions, allowing you to dynamically change the UI composition without interacting with the visual elements themselves.
Although MEF's capabilities are used to create views and resolve their dependencies, I don't see how they can be used to provide region capabilities such as UI composition, navigation, etc, on it's own.

If I had misunderstood what you meant, it would be helpful if you could elaborate a little more about what MEF capabilities you are referring to and how could they be used to perform UI composition.


Damian Cherubini
Jul 1, 2013 at 9:16 PM
Edited Jul 2, 2013 at 5:38 PM
First, thank you for your answer and for being so helpful in this forum.

Indeed, I was referring the different ways to compose UI and the degree of overlaping between them.

I meant to compare the different designs, as wholes, and not the MEF technology in itself and on its own as opposed to the usage of regions.
Actually, I wanted to check the argument that a design using (not only) MEF but without using regions can achieve
much of the same things we can do with regions.

Indeed again, MEF has no navigation abilities. But I envisaged a design intended to create multiple windows in which
instead of region navigation to views for content, we would have dynamic UI creation and deletion ( by the new windows). And besides, we can add custom navigation.

Regarding UI composition - we can use controllers and/or services and MEF's Import and Export abilities (that was what I meant by
Input and Output - and sorry for not being clear).

I do know that there are differences between the designs. I wished to discuss them and their possible implications.

Again, thanks.

P.S. - Essentially you are saying that the region concept encapsulates UI composition abilities that are missing in MEF
and that we would have to design on our own if we give up using the regions, and therefore the region concept can not be overlaping but complementary to using MEF ?
Jul 2, 2013 at 7:48 PM

I think I understand what you mean now.
In my opinion, this is relative to each scenario and how regions are used in them.

For simple scenarios where the regions are only used to problematically add and remove views for different parts of the UI, it could be possible to remove the regions and change the composition of the UI manually. This could be achieved using several different approaches: using controllers as you mentioned, managing visual states in the view, using data templates and view-model-first, etc.

However, this is not so trivial for more complex scenarios where navigation and region behaviors are used. The first one provide a mechanism to navigate and pass parameters back and forth between views in a decoupled fashion. The seconds are used to provide logic that would execute automatically when a change in a region occurs (and possible, affect the hosted views in consequence.) Hence, in order to remove regions for such scenarios, additional logic would be needed to provide functionalities similar to those ones.

Indeed, I believe that Regions and MEF are complementary rather that overlapping APIs. Regions are used to compose the UI but they have no container-like abilities to build parts like MEF does. For this, the Regions delegate the responsibility of building and initializing the views (when needed) to the composition container of your application (for example MEF.) Hence, in a Prism application the region API and MEF work complementing each other.


Damian Cherubini
Jul 3, 2013 at 7:17 AM
Edited Jul 3, 2013 at 7:20 AM

Prism was created as a set of best practices in designing WPF Composite applications. Regrettably, while there are many good books
and articles on WPF, there is only one book about Prism which actually rewrites the MSDN reference, and we must rely on MSDN
and blogs and forums for documentation.
That is why I wish to thank Mr. Damian and Mr. Federico for their efforts.

And that is why Mr. Damian may write a great book on the subject.

For I see he can do it.