Data Dictionary module

Topics: Prism v4 - Silverlight 4
Feb 17, 2011 at 8:11 PM
Edited Feb 17, 2011 at 8:12 PM


We have an app built with PRISM + Silverlight 4. The app contains multiple modules and they share a same set of lookup data dictionaries (i.e., mapping between code and description for different lookup classes). The way we want to implement it is to have a dedicated module for the Lookup service. This module will contain classes responsible for retrieving lookup (through asynchronous web request calls) and providing lookup service to consumers. Those classes will be registered in the Unity Container so other modules could use them.

The goal is to isolate the responsibility of retrieving lookup completely into the lookup module. Therefore when other modules use the lookup service, we are always certain data is always loaded (i.e., no check is needed. If lookup loading fails, the app should not start).

The main obstacle we hit is how to synchronize the module loading. We can define modular dependencies and have the lookup module loaded first. But because the data retrieval is asynchronous, when the web request for retrieving lookup is sent out, the process moves forward and continues loading other modules without waiting for the response. Is there a way to block loading modules (i.e., only load other modules when lookup data retrieval succeeded?) . Or is there a better way to do it and acheive the same purpose?

Help much appreciated. Thanks in advance.



Feb 18, 2011 at 3:02 PM

Hi MH,

Based on my understanding of your scenario, you might load your modules on demand after the lookup service finishes to load.

One possible way to achieve this is to load the lookup module on the bootstrapper and load the remaining modules on demand. For example, if you use a XAML file to register the modules that will be loaded on demand, you would need to specify InitializationMode="OnDemand" in your ModuleInfo element.

Finally, in the LoadAsyncCompleted event of your service request you can load the previous registered modules by obtaining a reference of the ModuleManager.

For example:

private void LoadAsyncCompleted(object sender, EventArgs e)
      var moduleManager = ServiceLocator.Current.GetInstance<IModuleManager>();

You can read more about modularity in Chapter 4: Modular Application Development, specifically in the Registering Modules Using a XAML File section and the Loading Modules on Demand section

I hope you find this information useful.


Miguel Bronzovic


Feb 18, 2011 at 6:31 PM
Edited Feb 18, 2011 at 7:21 PM

Hi Miguel,

Thanks for the help. I think the approach  does solve the issue.

However, I have another dillema when considering where to put the code of dynamicly loading dependent modules.

It seems to me that it's not very flexible to load the modules directly in the LoadAsyncCompleted event of the service request. For example, what if I have multiple modules I want to load and complete the asynchronous call first before loading other modules? Then I think it might work if those "first priority modules" just fire an event to event aggregator when those asynchronous calls are finished. First I was trying to subscribe to these events in bootstrapper (override ConfigureServiceLocator).. But then it seems to me the bootstrapper contains code that's not supposed to be there.... So should i actually create another Module specifically for managing the synchronization of module loading? this module will subscribe to all the event that "priority modules" fires when asynchronous service request finish and this module will be responsible for dynamically loading all other dependent modules.

Does it look all right? or there is a better approach to improve the architecture?


Feb 18, 2011 at 7:02 PM


The approach you are mentioning (defining a component to manage the load of dependent modules) seems a valid possibility for a complex scenario like the one you have mentioned. Please note that the component doesn't necessarily have to be placed in a separate module; for example, it could be placed in the shell project.

The benefit you will get from following your approach will be that your modules will not be responsible for knowing which module to load after the asyncrhonous operation is completed; the only component that will be aware of the module's load order will be the "module load manager" that you will define as a separate component.

Please let me know if this information is useful.


Miguel Bronzovic