Building a Presentation Framework with Prism for Silverlight | John Papa

John Papa

Evangelist on the loose

Building a Presentation Framework with Prism for Silverlight


I build a lot of line of business applications and in the process there are always certain aspects I have to tackle that I like to call the presentation framework collectively. Common aspects of a presentation framework are (not a conclusive list, but a good start)

  • transitions from screen to screen
  • showing progress when busy
  • loading and/or activating screens 
  • destroying and/or hiding screens
  • getting data from web services
  • mapping models for the UI specifically
  • validation
  • including a default button (enter key submission)
  • tracking changes
  • can a screen be navigated away?
  • communications between screens and their colleagues

I could go on and on. And none of these items are out of the ordinary … many applications have to face these same issues. I have been working on a version of a presentation framework that uses Silverlight, MVVM and Prism (and Unity) that will be published through the Prism team later this year. I am putting together the code samples and demonstrations now to show how to reap the benefits of the presentation framework, Prism, MVVM and Unity all in the context of building Silverlight 3 LOB applications. So keep an eye out for that article series … I will announce it on my blog when it is close to kick off time.

But back to the presentation framework …

Ward Bell and I have been chatting about our thoughts and exchanging ideas on how we handle our own presentation frameworks. In an effort to get on the same page with the world, we have conformed to using some common terminology because frankly when it comes to patterns and frameworks we technology people are horrible at being clear. How much can we all take of acronyms and funky named patterns can we take? Ward Bell and I have also been chatting with gurus like Glenn Block and Jeremy Miller, who have a great grasp on these concepts. One thing of many that Jeremy does quite well is express the concepts in clear terms. So I decided to talked about my presentation framework using some of the same names as Jeremy and Ward.

The overall goal is to handle many of the presentational aspects of LOB UI’s (see bullet list above). So what are these players in my framework? Here is a brief description of the players and what they do.


A screen in this context is the class that handles coordinates (or directs) the Model, View and ViewModel (the MVVM triads). A screen is a logical place to coordinate the marrying of a View to a ViewModel too. This way the VIew knows not about the VM and the VM knows not about the V. It must implement the IScreen interface. There will be screens in the modules of the Prism based modular application and there will most certainly be many screen instances (ProductScreen, EmployeeScreen, etc).


An interface that all screens will implement that helps with things like CanLeave and CleanUp. This interface is the means by which the other framework items can talk to screens. I put this in my infrastructure project since it generic and not app specific.

Screen Factory

The screen factory instances go hand in hand with a Screen implementation in each module (1 Screen Factory for 1 Screen). The screen factory is in charge of creating the screen and hydrating what it needs. It implements the IScreenFacotry interface, which has a CreateScreen method. The ScreenFactory classes are registered with the presentation framework (with the ScreenFactoryRegistry singleton class) so the ScreenConductor can crank them up when needed.


All ScreenFactory instances implement this interface and its CreateScreen method. The other presentaiton framework talks to the ScreenFactory classes through this interface. This goes in the infrastructure project.


The ScreenFactoryRegistry contains a registry of all of the screen factory classes (using the IScreenFactory interface). As modules are loaded, they can register their ScreenFactory classes with the ScreenFactoryRegistry. This does not “new them up” but instead puts them in a registry so they can be accessed later as needed and on demand. Of course, this requires that someone (the individual modules) register the ScreenFactory classes. The modules are ideal for this since they know which they will need. This class has GetFactory, HasFactory, a ScreenFactoryDictionary and an assortment of helper methods. This is also in infrastructure and is a singleton class created through Unity.

Screen Conductor

The ScreenConductor class is the grand poobah in the presentation framework. He coordinates the loading and destroying of screens. He subscribes to published events through the event aggregator in Prism and is told which screens to load. The Screen Conductor knows about the registry, so it looks up the proper screen factory in the registry and starts the hydration process. A lot of the mechanics happen down here including visibility services, popping screens into regions, loading subjects for screens, deciding to hide or destroy a screen (activate or load as well), and so on. It is the brains. This is also in infrastructure and is a singleton class created through Unity.


The ScreenConductor class has a ScreenCollection class which contains all of the activated screen instances. The collection is maintained by the screen conductor.


The subject is something that is specific to a screen and helps the screen gain its context. For example, the subject could be the information that the screen needs to load itself with employee “John Smith”. Or the subject can be empty, in which case the screen is blank.

While this is not a conclusive list nor is it very detailed, I will be explaining how all of these classes work together in a Silverlight/MVVM/Prism in my upcoming article series. In the meantime, I will blog about some of the progress as I go, listen to suggestions, and when I am done I plan on doing some videos to follow up the article series too. Keep in mind that this is one man’s opinion of how the framework will evolve. I have used some fairly common concepts and tried to stick with some of the same naming conventions others have gone with because I want this to be something that is easier to adopt.

tags: Silverlight
  • Anonymous

    Pingback from Reflective Perspective – Chris Alcock » The Morning Brew #389

  • Anonymous

    This sounds great! We’ve started designing a new Silverlight 3 student information system, for use here at the Polk County School Board, and this is the same direction we’re heading in. Our goal is to allow the user to work with multiple student screens, but only show one at a time. We plan on having them access the other open screens by going to the icon for student screens and selecting or closing the screens from there, much like the Windows 7 taskbar.
    I’m looking forward to your articles. Any chance on doing a talk at either the Lakeland .NET UG or Tampa .NET UG?

  • Anonymous

    I also build LOB apps. What I see missing is a good set of input controls – input mask, money text boxes, etc…
    These are essential. (I like the demos right now that show a phone number with no mask and then say ‘enter it right’ – they must not work with real users… lol)
    What are you using for your input control JohnPapa ?

  • JohnPapa

    Steve … I have written some masked controls. But I often use the 3rd party controls available for those purposes. There are some good ones out there.
    Evan … Nothing on tap this summer … but Healy and I have discussed a Prism/Silverlight/MVVM day in Tampa. Might need to rekindle that if there is interest.

  • Anonymous

    Care to share any code? :) Nice article.

  • Anonymous

    Have you looked at Caliburn? It’s over 2 years old and works with WPF and Silverlight. It does everything you mentioned plus a number of additional things. It has been used on all of my company’s apps, has been adopted by a number of other companies and has a growing community contributing patches and samples; so it has a proven successful track record.

  • Anonymous

    I’m working up my chapter on the “Event Aggregator” pattern for my book this evening

  • Anonymous

    Sounds very cool (and useful) John! I will be watching your blog to see how it evolves.

  • Anonymous

    Do you have some code. Looks interesting. Specially the Conductor.

  • Anonymous

    Jeremy Miller just published a post asking for feedback on how we activate and deactivate our screens in our application frameworks (what I also call a Presentation Framework). I started replying in the comments then realized it was going to be too long

  • Anonymous

    Jeremy Miller just published a post asking for feedback on how we activate and deactivate our screens

  • Anonymous

    Hi John,
    Any idea when you might have some code for us to look at. I really like the approach you are taking here and would like to use it on my new project.

  • JohnPapa

    I am writing an article for MSDN on this topic and will be publishing it in a few weeks. I’ll share it all then :)

  • Anonymous

    Any word on when the article will be published?

  • Debashish Gupta

    Hi John ,
    How can we pass values from View1 of a Module1 to another View2 of Module2 and opening that View2 as well.
    I added a field called MessageParams in ScreenActivateEvent class.
    and Published the event from View1 same as the ShellVM dose.
    But not able to pass the MessageParams to View2.
    Debashish Gupta

%d bloggers like this: