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.

Screen

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).

IScreen

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.

IScreenFactory

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.

ScreenFactoryRegistry

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.

ScreenCollection

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

Subject

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.