New Post: Creating a multple window app like Outlook

Hi Brian,

I carefully studied the IG Outlook code and applied a similar approach (scoped regions and a dialog service) to a reasonably complex Prism app (Mike Taulty's Email client app (ported to WPF)) that has been so far single-shelled. I encountered the following issues:

1. Calling regionManager.RequestNavigate() in a secondary shell's view model classes actually changes the view in the very first shell. This is because the view model class's constructor asks the Unity container to inject the IRegionManager, which is the one for the very first shell. I would need to add some code for every view model class that calls the RequestNavigate() method to get the scoped region manager that is dedicated for that particular shell. A shared service with a dictionary could do it, but it would certainly complicate the software because those multiple scoped region managers need to be carefully managed.
   
2. When I created a new Shell and called the scopedRegionManager.RequestNavigate() with the main content region, I had to also issue RequestNavigate() to all nested regions that are defined inside the main content region to show all views. In the single-shelled version, those were done in each module's InitializeModule() method. But now, I need to know those implementation details beforehand.
   
3. With the scoped region manager, the RegisterViewWithRegion() does not work. The app has a lot of "static" area where the view discovery works just fine. The IG Outlook code never uses it because of the scoped region manager, I presume. I had to change to RequestNavigate() calls, which has an additional burden of registering the view classes with the Unity container as "object". With the view discovery, we don't need to register views to the Unity container.
   
4. The EventAggregator also needs to be scoped. I probably should use the "filter" parameter for the Subscribe() method and provide the scoped region manager as the key for the filter. But again, I don't know how to get the scoped region manager in view model classes.
   

The secondary bootstrapper approach has none of those issues with the view discovery, region navigation, and event aggregation because all of those services are dedicated to the newly created Shell only, thanks to the also duplicated Unity container. I created and registered a separate EventAggregator in the main bootstrapper, named it "Global", and then passed it to every secondary bootstrapper as a singleton. This "global" event aggregator is used to create a new instance of the Shell. I can easily add [Dependency("Global")] attribute before the event aggregator parameter in the view model constructors so that the secondary Unity can inject the global one, rather than its own one. So far, it's been working beautifully. Very little code was needed to support multiple shells (again, so far).

You used rather strong words - "DO NOT use two bootstrappers". Would you please explain why it is such a bad idea?

Thanks