I’m sure we all agree that decoupling is the key to creating extensible and maintainable applications. Prism is something that will help us achieve this using a bunch of different techniques. Prism is designed to decouple UI components from each other at various levels. Below is a good diagram showing how the different parts are separated:

The right part of the diagram shows common services that can be configured to be used at run time. We will discuss the common ones that would be most useful to someone using Prism for the first time.

Modularity is a concept in Prism where you can group all the vertical functionalities of your application into a module. If a certain part of your application can be pulled out from the entire application and still be useful, then it’s a good candidate for a module. Modules may or may not have visual elements. The decision of separating a group of functionality into a module should really be based on whether it may be reused by a different application in the future. My rule of thumb is, things that go well together would most likely be useful for someone else.

Modules are also where UI components reside in. In Prism lingo they are known as views. Views are screens that visualize the data that is held inside models. Models are exposed to the views thru view models, which hold both the state of the view and the operations that can be done on the models exposed by that view model. This is an overly simplified view of MVVM, we will discuss this further in the Commanding section.

To be honest, modules aren’t exactly very exciting. They’re no different from creating a component that could be reused across different applications. The thing that makes them interesting is how they’re loaded and displayed on the shell (empty application where everything is loaded eventually).

Looking at the upper left part of the diagram, you will see that shell is where the views are loaded. The shell and views do not know each other, thus making the loading interesting. This is where regions come into the picture. A region is a fragment of XAML code that states that a certain view will appear “here”. Regions are assigned on XAML by attaching the RegionManager.RegionName property to any control that has a Content property. This will inform Prism that any view registered with that RegionManager.RegionName will appear on that control’s Content property. This technique of having the shell switch views depending on which module is loaded provides a way to decouple the views of the module from the shell.

The module catalog is a repository for all the modules that are available for the application. There are a number of ways to load modules into the module catalog. The most interesting one would be on-demand. Modules may be loaded into the application as the need arises. This is a special advantage for Silverlight applications since it would minimize the size of the downloaded XAP file(s) depending on the need of the user.

The bootstrapper is the thing that ties all the Prism components together. This is also the thing that instantiates the shell and module catalog.

You can think of services as modules that do not have views. A service would be a chunk of functionality that would most likely be used by most if not all the other modules. Logging and Authentication would be good examples of services. The guidance provided by Prism with regards to building services is pretty simple. First ensure that you expose a contract that can be distributed to all the interested client modules for the service. The contract would usually be an interface class that the client modules can implement against with no risk of commitment to a specific service. The second step is a bit more interesting. Developers should create instances of services

Back in early 2000, ASP.NET promised a way to separate presentation from content with the code-behind model. It made true it’s promise but we ended up with cs files that are wired up to events on the aspx file. This made unit testing very difficult. You would need to understand what the event handler method was supposed to do and what values it would affect. Button_Click doesn’t exactly tell you what the method is going to do other than its going to execute when the button is clicked. PlaceOrder_Click is better but since the method is still an event handler, it won’t be able to enforce an Order parameter. This usually leads to instances of classes hap-hazardly used across different methods on the same code behind file. Thus making unit testing, especially white box testing, next to unbearable.

We need a way to communicate between all these decoupled components. Since they all do not know each other, there has to be a way to send messages across the sea of anonymity. Event aggregation is here to help. It is a publish – subscribe mechanism that allows components to listen to events that they are particularly interested in. Components can also publish events and event send a payload. All components listening to a published event get informed and sent the payload.

One of the major issues with a publish – subscribe mechanism is having subscribers that are no longer listening. There is a way to overcome this problem with Prism. All you need to do is subscribe to an event with a weak reference. You can do this by setting the KeepSubscriberReferenceAlive to false when subscribing to a reference. This way, you won’t need to manage removing yourself from that event’s subscriber list.