Composite Application Library (Prism) and Silverlight

With the advancement in the Silverlight technology starting with the 1.0 release to 2.0, 3.0, and lately 4.0, Silverlight is loudly saying WOW “Watch Out World.” Can you guess which world I am talking about here? It is the RIAs world! Really WOW!

All the features already delivered in Silverlight or on their way to be released are great and you can use them out of the box in your applications. What applications am I talking about? For sure, simple applications-those that cannot be tested with Unit Testing, have a single UI containing all features, have their UI holding all the driving logic, and were developed as one big chunk of code mixing together all functionalities hence tightly coupling the code. Consider larger Silverlight applications:

• What happens when your application starts growing?
• What happens when you have to extend an application with additional features?
• What happens when the developer and the designer have to work side by side on the same application when the application fills the UI with application logic with no means of separation of concerns?
• What happens when you want to employ unit testing for the application?

The above is just a sample of questions you start asking yourself when you start developing large-scale Silverlight applications.

One way to mitigate the problems mentioned above is to follow proven design patterns that have helped solve so many software-oriented problems over the years. One pattern that best suits Silverlight or WPF development is the MVVM, model view view-model design pattern.

The MVVM helps in the separation of concerns between the UI design of the application (View), the behavior (View-Model) of the UI, and its interaction with the data source (Model).

M is the model or data source where data comes into the application. V represents the View where the layout of the applications is defined. VM encapsulates the UI behavior and plays the role of the “link” between the V and the M so that data coming from the model gets bound to the UI controls displayed by the application. Shawn Wildermuth has an informative article on how MVVM applies to Silverlight that you can read by following this link: Model-View-ViewModel in Silverlight 2 Apps (http://msdn.microsoft.com/en-us/magazine/dd458800.aspx).

MVVM helps to improve the architecture of the application mainly by allowing separation of concerns in terms of source code and UI design and making sure the source code fits for unit testing. However, it does not satisfy the requirements of large-scale applications. This is where third-party libraries like the Composite Application Library (Prism), developed and maintained by the Microsoft Patterns and Practices team, helps in building robust and well-organized Silverlight business applications.

Throughout this article, I will uncover the details of Prism and I hope it will help you start designing your Silverlight applications, taking into consideration whatever Prism offers you to build robust, fast, and maintainable solutions.

Composite Application Library (Prism)

Prism is a mixture of both development guidance and framework published by the Microsoft Patterns and Practices team to help developers build modular, loosely coupled, and multitargeted code applications in both Windows Presentation Foundation (WPF) and Silverlight technologies.

To cater to the ongoing changes in a growing application without affecting existing features, Prism promotes the use of modules to split the application into logical units where each unit is independent of the rest of the modules in the application. Hence, changing one module has no effect on the rest of the modules in the application. Prism provides the infrastructure to create modules and load them into the application.

When it comes to loading modules, Prism provides two ways to do so. One is to load the module upon application loading. The other option is to load the module on demand.

For instance, if your application has a module that presents reports to be viewed by managers at the end of each month, then there is no use in loading the reporting module whenever the application is loaded. A better solution is to go to the server whenever the reporting module is accessed by a manager and download it before it is viewed. This is an efficient technique that minimizes the time needed to load the application.

When developing a module it is important to remember the following:

1. Modules should not add references to other modules, hence tightly coupled modules are not recommended.
2. Modules should focus on a single or set of related functionalities.
3. Modules should communicate between each other in a loosely coupled fashion.
4. Each module should load its own views.
5. Modules should not manage their dependencies. Prism helps in this by making use of the Dependency Injection (DI) pattern.
6. There are other features that modules should have which you can read about in more detail in the documentation that accompanies Prism libraries.

A major architectural decision to be made when developing a new module is to make sure the module manages its own view components. This means when a module is loaded it also loads a certain view, or UI component, into the main application. In this way, each application is a collection of composed views that are loaded by each module initialized. Hence the concept of UI composition that Prism supports. When you develop an application in Prism, you mainly start by defining a Shell component. Think of the Shell component as the Master Page in ASP.NET. The Shell contains placeholders, named regions, the same as Master Pages contain ContentPlaceHolders. At run time, certain content will be loaded into those dynamic placeholders and there you will get a composed UI from several places.

In Prism, you define a Shell component, representing the application’s visual appearance, with run-time-loaded placeholders, or regions. Each module when loaded must register its views, which are nothing but UserControls, to specific pre-defined regions on the Shell. When the application loads, Prism also loads modules registered to be loaded at application startup. Once Prism loads a module, it loads the views registered with regions and places each in its proper position on the Shell. Therefore Prism not only supports functionality composition, but also UI composition where each module is responsible for its own functionality or set of features together with managing the UI that presents the functionality to the users.

Prism provides two techniques to register views to regions: View Discovery and View Injection. The former maps a view to a region name so that when the region loads, it dynamically queries an internal service inside Prism to detect what views are mapped to it and loads them on the spot. On the other hand modules making use of View Injection dynamically add views’ instances to regions. Based on your requirements, you can make use of those two techniques provided by Prism.

Another major feature to be considered when developing modules in Prism is that modules should be loosely coupled. At the same time they need a way to communicate or interface between each other. Luckily Prism provides Event Aggregation that allows modules to publish and subscribe to events. Consider a simple application where you have two modules: the List of Employees module and the Employee Details module. The two modules are totally isolated from each other; the only way they communicate is through an event “published by” the List of Employees module when an employee is selected, and “subscribed to” by the Employee Details module. When the Employee Details module is first loaded, it automatically subscribes to the well-known and agreed-upon event by the List of Employees module. Therefore, when the event is fired upon the selection of an employee, the event handler that was registered by the Employee Details module at load time will be fired. This way, the two modules communicate in a very loosely coupled fashion without having to know any details about each other.

Moreover, I mentioned above that modules should not manage their own dependencies. Consider for example a module that needs to connect to a Web Service that is a common data source to the application being developed. The module has the option to use either of the following two techniques:

1. Add a Web Reference to that Web Service to create a local proxy instance.
2. Let Prism provide a proxy instance.

Assume your application is composed of several modules that require access to the same Web Service, and in each module you need to repeat the same steps to add references to that Web Service. This is complex and requires lots of work by the module itself.

What if Prism can provide each module a proxy instance to connect to that Web Service?

Then each module will not bother managing a reference to the Web Service and will not worry, for example, if the address of that Web Service has changed. Prism makes use of DI containers to manage and provide dependencies to modules instead of having those modules manage their dependencies on their own. Prism also makes use of DI containers to inject dependencies to classes that are not bound to a specific DI container. On the contrary, Prism employs Service Locator, another component provided by the Patterns and Practices team, to generically wrap any container used. It also ships with a single Service Locator that wraps the Microsoft Unity container.

Back to the example, the Shell application creates and manages a proxy to the Web Service in question, and then registers that instance with the container as a singleton instance. Therefore the proxy instance is now accessible to any module in the application where a module can resolve that instance and use it. One requirement though is that each module must request an instance of the Container service as one of the parameters of the module definition class constructor.

One last feature to cover is the perfect support for developing Silverlight applications based on the MVVM and Presentation Model design patterns. These design patterns focus on the separation of concerns between the XAML, representing the UI, and its behavior and state. Hence, the functionality of a view is now grouped into the ViewModel class that is married to the Data-Context of the view. In addition, following one of those design patterns, especially MVVM, allows you to write clean and well-separated code available for unit testing.

Having this brief overview on Prism, it is time to start seeing how these concepts get implemented by code.

By: Bilal Haidar

Bilal Haidar is a graduate from Lebanese American University with a double major in Computer Engineering and Computer Science with distinction in 2004. He has been a Microsoft MVP (ASP/ASP.NET )for two consecutive years, ASP.NET author at the ASPAlliance.com (http://www.aspalliance.com/) with a total of 10 articles, and works as a system developer at one of the leading construction companies in the world, Consolidated Contractors Company (CCC). Bilal follows the latest technologies in the field of .NET development. When he is out of his office, Bilal spends most of his time either reading and researching or working on his private freelancing projects.

You can read Bilal’s blog at http://bhaidar.net where he posts tips, tricks, and tutorials on .NET development-related stuff.

bilal@bhaidar.net