Since a Prism application is composed of a collection of loosely coupled modules, modules can be updated without requiring the whole application to be recompiled. But more importantly (for me that is) is the ability to add or remove modules dynamically (through configuration).

In Part2 we indicated that there are three different ways to specify the modules that make up a Prism application. We can specify them in a special section of the config file, in a pre-defined directory, or programmatically. When the application starts up, it will load the modules that have been specified. A consequence of this is that we are able to have each installation be a different version of the application!

In the sample code for this article I’ve chosen to use the config file as the mechanism to specify the application modules. The code below shows how the modules are specified.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="modules" type="Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite"/>
  </configSections>
  <modules>
    <module assemblyFile="Modules/WidgeNet2.Reporting.dll"
      moduleType="WidgeNet2.Reporting.Reporting, WidgeNet2.Reporting"
      moduleName="Reporting"/>
    <module assemblyFile="Modules/WidgeNet2.Weeble.dll"
       moduleType="WidgeNet2.Weeble.Weeble, WidgeNet2.Weeble"
       moduleName="Weeble"/>
    <module assemblyFile="Modules/WidgeNet2.Weebit.dll"
            moduleType="WidgeNet2.Weebit.Weebit, WidgeNet2.Weebit"
            moduleName="Weebit"/>
  </modules>
</configuration>

In Part2 we also indicated that by overriding the GetModuleCatalog() method in the Bootstrapper class we can specify the mechanism we want to use for module identification. Since I chose the configuration file approach, we make use of the helper class ConfigurationModuleCatalog to provide that functionality. The definition of the special section is pretty intuitive and all you have to do is add an entry for each module that is to be loaded.

In the sample code each module also includes the associated UI for each module. This makes it trivial to add or remove functionality from the application. If you comment out the entry for the Reporting module in the sample code and re-run the application you will see that the Reports tab is no longer available to the user. Also remember that the definition of a module is up to you. It could be several screens of related functionality or it may be a simple service with no UI.

Another facility built in to Prism which facilitates the loose coupling of modules is the Event Aggregator. This is essentially a publish/subscribe service for custom events. There are a number of common design conditions that can be solved or improved using the mechanism provided by the Event Aggregator.

One situation that comes up often is synchronization of disconnected data. In the sample project there are two screens that display data related to Weebits. One screen controls the creation and editing of Weebits (Weebit Editor) and another screen displays the available Weebits with which the user will define Weebles.

The Weebit Editor screen will always have current data since it controls what is in the data store. The Weeble Editor screen loads the available Weebits when it is initially loaded but if new ones are created the list won’t be current. This is a typical problem when there are multiple screens for the same data source.

One, not so elegant solution, is to provide a ‘refresh’ button on the secondary screen which will refresh the screen with the current data. Another less elegant solution is to provide a timer that will refresh the screen periodically with the current data in the data store.

The right solution is to have the data store notify the secondary screen(s) whenever the data has been updated. In the sample code we have a service (WeebitDataSvc) that manages the data associated with Weebit objects. What we want is for that service to generate an event (publish) whenever a new Weebit is created. Using this approach the Weeble screen can subscribe to the event that will be published and will always have the latest list of Weebit items.

The first thing that’s needed is to define a class that will be used to communicate information regarding the creation of a new Weebit (the event). The following code shows the definition for our NewWeebitEvent class.

using Microsoft.Practices.Composite.Presentation.Events;

namespace WidgeNet2.Common.Events
{
    public class NewWeebitEvent : CompositePresentationEvent
    {
    }
}

The event class derives from CompositePresentationEvent and also defines the payload that will be communicated with the publication. In our case all we want to communicate is the name of the newly created Weebit. But we could just as easily have sent the whole Weebit object as the payload. The CompositePresentationEvent class provides the Publish and Subscribe methods which clients use to subscribe to publication events and to publish events.

Once you have the message defined then it’s just a matter of indicating who is going to publish the event and who is going to subscribe to the event. The WeebitDataSvc controls the data store for the Weebit data so it will publish an event when a new Weebit is created. In the constructor for the service we pass in a reference to the Prism EventAggregator service which is then stored locally and used to publish our event. Here’s the code for that.

public bool NewWeebit(WeebitData weebit)
{
	…
        //Publish the event
        eventAggregator.GetEvent().Publish(weebit.Name);
	…
}

The code simply gets a reference to the NewWeebitEvent using the GetEvent method of the EventAggregator. We then call Publish on the returned reference passing the weebit name as the payload.

And on the Weeble Editor screen we subscribe to the event as shown below.

public WeebleEditorViewModel(IWeebitDataSvc weebitDataSvc, IEventAggregator eventAggregator)
{
    this.weebitDataSvc = weebitDataSvc;
    this.eventAggregator = eventAggregator;

    //Get current list of weebits
    weebits = new ObservableCollection(weebitDataSvc.GetWeebitNames());

    //Subscribe to new weebits event
    NewWeebitEvent newWeebitEvent = eventAggregator.GetEvent();

    if (subscriptionToken != null)
    {
        newWeebitEvent.Unsubscribe(subscriptionToken);
    }

    subscriptionToken = newWeebitEvent.Subscribe(NewWeebitEventHandler, ThreadOption.UIThread, false, null);

}
public void NewWeebitEventHandler(string newWeebitName)
{
    //Just add it to the list
    weebits.Add(newWeebitName);
}

A reference to EventAggregator service gets passed in the constructor. Subscribing to an event is pretty straight forward. The EventAggregator maintains a list of subscriptions to publication events. We first get a reference to a NewWeebitEvent by using the GetEvent method of the EventAggregator. We then use that reference to subscribe to that publication by calling the Subscribe method and passing a reference to our event handler. The EventAggregator returns a token so that we can maintain a reference count of our subscriptions. This is important so that we don’t get called multiple times for an event. When the WeebitDataSvc publishes the event the EventAggregator will forward the payload to all subscribers of that event using the event handler.

The EventAggregator is powerful feature provided with Prism which will help in de-coupling your components. However it only helps with inprocess communication. We’ll explore another approach for an inter-process publish/subscribe service in a subsequent article.