Windows Phone 7 Developer Launch - Learn More
kick it on DotNetKicks.com   Shout it  

MVVM with Prism 101 – Part 1: The Bootstrapper

Source Code

I recently spoke at a CodeCamp put on by the Northern Utah .NET User Group (NUNUG) on implementing MVVM using Prism. I hadn’t spoken in a long time and so I was over prepared – way over prepared. Then to top in off in my nervousness, I blew the whole presentation by starting 15 minutes late. I was the session after lunch and I assumed lunch was an hour, so I mistakenly assumed my session started at 1:00 PM. :p

Embarrassing stories aside, I really learned a lot more about Prism and Silverlight and what an enterprise-class implementation of Prism looks like. So I am writing a redux of my previous post on Prism and Silverlight. If you want a shorter overview of things, read that one first. However, I intend to introduce new concepts and go deeper than I did in my previous article. This is the first of this series.

MVVM

Before I get started I would like to just make a short comment about MVVM. The pattern known as Model View View-Model is in it’s pure form very simple. You have a Model (your business/domain model), a View (in the case of WPF/Silverlight is your Xaml file) and the distinguishing piece of the pattern: the View Model.

The View-Model is a composite of the abstraction of you view’s state and behavior. The idea behind the View-Model is to create an abstraction of your view which has little to no dependencies on your view. There should be no references to UI controls or classes specific to the UI (like the Visibility enum). There should be no event handlers like what is common in a code-behind class. Your View-Model should know nothing of your UI.

The reason for this and why it is possible has a strong tie to the way data biding works in WPF/Silverlight. I won’t directly get into the specifics of data binding, except to say that because of the specific way you can bind UI elements to objects in a strongly-typed manner MVVM has become the de facto standard pattern for developing applications for WPF/Silverlight.

Once you get MVVM it will become second nature to you. Its power lies in its simplicity. The complexity of implementing MVVM is more about the framework you are using than actually using the pattern. I will explain more about that last statement in a future post. I when I actually get to discussing MVVM specifically I plan on demonstrating what I’d like to term “poor man’s MVVM” so I can demonstrate the MVVM in a more pure form. The rest of the series is either specific to Prism or specific features you’ll want to implement as you’re developing your application.

Bootstrapper

The Bootstrapper is your starting point when developing any application for Prism (aka Composite Application Library for WPF/Silverlight). The Bootstrapper is basically class representing your App_Startup method. Once you’ve completed your Bootstrapper you just initialize it and call Run() inside of App_Startup, like this:

   1: private void Application_Startup(object sender, StartupEventArgs e)
   2: {
   3:     //replaces the call to "this.RootVisual = new Shell();"
   4:     MyBootstrapper bootstrapper = new MyBootstrapper();
   5:     bootstrapper.Run();
   6: }
   7:  

Just remove the call (in Silverlight) to this.RootVisual and replace it by instantiating your Bootstrapper and calling Run().

The basic purpose of your Bootstrapper is to initialize your Inversion of Control (IoC) container and register all the types you’ll need for Dependency Injection (DI). Because of this your Bootstrapper will inherit from an abstract class named after your specific IoC implementation. You can use any library you choose: Ninject, StructureMap, Unity, etc. However, Prism actually only provides a single implementation of Bootstrapper – UnityBootstrapper. If you want to use another container library, you’ll either have to write your own or find an implementation out on the web. This isn’t hard to do as there are a number of implementations out there for each of the widely used libraries.

There are 3 common tasks that you’ll do every time your create a new Boostrapper:

  1. Setup ModuleCatalog
  2. Configure the Container (IoC)
  3. Create Shell

I’ll go over each of these in detail:

Setup ModuleCatalog

A module (in terms of Prism) is a class which implements the Microsoft.Practices.Composite.Modularity.IModule interface. A module represents a pluggable piece of the composite whole. When planning your application you will isolate it into logical parts. If your application were an rss reader you might have modules for Content, Tags, PopularItems, RecentItems, Favorites, etc. They may or may not need to communicate, but you can certainly add , remove and rearrange each one without affecting the others. This is an example of a module.

Think of ModuleCatalog as a registry of all the modules you plan to load in your application. Once you register them when your application loads they will be loaded in the order you registered them and then each module in turn will inject your views into the main window of your application.

Setting up ModuleCatalog is simple:

public class Bootstrapper : UnityBootstrapper
{
    protected override IModuleCatalog GetModuleCatalog()
    {
        ModuleCatalog catalog = new ModuleCatalog();
 
        catalog.AddModule(typeof(ServicesModule));
        catalog.AddModule(typeof(EditorModule));
        catalog.AddModule(typeof(HistoryModule));
 
        return catalog;
    }
}

For the most part, that’s all that’s required. At the very minimum you must return an instance of ModuleCatalog – whether or not you register anything with it. But if you don’t you aren’t likely to see much more than just your shell when the application loads. So you’ll register each module you’ve defined and possibly declare any dependencies (more on that when we discuss modules) and finally you’ll return the catalog to the Bootstrapper.

It is important to note that the order you register your modules is the order they will load in, so pay attention or you’ll have some troubles when your application starts up. I’ll address managing dependencies between modules later in the series when I talk about implementing modules.

As a note I will mention that there are other ways to configure the module catalog and to load modules. Some are dependent upon whether you’re using WPF or Silverlight, but both technologies provide some way or another for you to load modules dynamically or on demand or to use configuration of some sort (WPF – config file / Silverlight app.xaml). But I won’t be going into any of these methods in this series.

Create Shell

The shell is comparable to an ASP.NET MasterPage. The shell is usually a UserControl or Page.  Whereas a MasterPage uses ContentPlaceHolder objects, Prism uses Regions (more on that in my next post). For now, a region is an attached property for specific xaml objects which designates where you can inject your views to display them.

When it comes to Silverlight applications, an important thing to note about the shell is that it will become the RootVisual object. If you aren’t familiar with RootVisual, it is important to note that it can only be set once - you can’t change it once it has been set. But here’s the nice thing about using Prism, the regions you define later on allow you to dynamically replace or load additional content as you need. So your shell will provide the placeholders for you.

Other than that all you really need to remember is to initialize the class which represents your UserControl or Page (the code behind), set it as the RootVisual (call Show() if you’re developing for WPF) and return the instance from your method. The Bootstrapper implementation you inherit from will then register any regions you’ve defined in your xaml with the RegionManager service. Here’s what your CreateShell method should look like:

protected override DependencyObject CreateShell()
{
    Shell shell = Container.Resolve<Shell>();
 
    Application.Current.RootVisual = shell;
 
    return shell;
}

Conclusion

I will continue this series next time by talking about the Shell and Regions. For now, here is a sample project which demonstrates what we’ve just discussed.

tags: , , ,

kick it on DotNetKicks.com   Shout it  

Feedback

# MVVM with Prism The Bootstrapper

Gravatar MVVM with Prism The Bootstrapper 10/5/2009 8:11 AM | Pingback/TrackBack

# MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar MVVM with Prism 101 – Part 1: The Bootstrapper 10/5/2009 8:13 AM | Pingback/TrackBack

# Silverlight Cream for October 04, 2009 -- #704

Gravatar Silverlight Cream for October 04, 2009 -- #704 10/5/2009 8:14 AM | Pingback/TrackBack

# MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar MVVM with Prism 101 – Part 1: The Bootstrapper 10/7/2009 9:36 AM | Pingback/TrackBack

# MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar MVVM with Prism 101 – Part 1: The Bootstrapper 10/7/2009 9:37 AM | Pingback/TrackBack

# re: MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar Mark,
How integrate SL3 (Prism 2.0) solution with MOSS Web Application?
Andrzej 10/8/2009 2:30 PM | Andrzej

# # re: MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar Andrzej, sorry but I can't answer that one for you. I've never used MOSS.

However, Silverlight is independent of what you're using as a web application platform. You could host a silverlight application on an apache web server and communicate with a PHP application if you wanted to.

It all really depends on what your silverlight application does, whether or not you're communicating with the server and if you are then how you're communicating with your server.

Finally, Prism has even less to do with the question. Prism doesn't communicate with your web server. Prism is a framework for building a composite application from modular blocks (usually projects). So even though I know absolutely nothing about MOSS I would go out on a limb and say you don't need to worry about it - you can develop your SL/Prism app independently of your MOSS application. If you are trying to communicate with MOSS via SL, you can do that as well but I couldn't tell you how.

Someone jump in if I'm totally wrong here. 10/8/2009 5:42 PM | Mark J Miller

# re: MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar I've been struggling to learn WPF itself along with the, Composite/Prism and MVVM patterns separately. I hope this is tutorial will (finally) be the one that can tie them together for me!

However, my first live app will likely be WPF, not Silverlight (which will be several months off, if not next year). What changes would be necessary to use your example project in WPF rather than Silverlight ? 2/19/2010 1:26 PM | David

# re: MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar I'm pretty sure the code will compile and run fine as a WPF app as well. I don't believe I have any dependencies on specific SL components. However, you will need to re-create the projects as Windows Class libraries and the Shell project as a WPF application and make sure to point the project references to the correct .NET Framwork Class libraries instead of the Silverlight (v 2.0.5.0) versions. 3/5/2010 1:22 PM | MarkJMiller

# re: MVVM with Prism 101 – Part 1: The Bootstrapper

Gravatar Thanks for the series and I learned a lot. One question I cannot find any good answer is how to load modules in the UnityBootstrapper from a configuration file (for silverlight project). I used Spring.NET for my previous winform project and it was useful using configuration file to add new modules so different developers did not have to constantly change the bootstrapper project and add reference to new modules. Can you somewhat elaborate or point to a right direction please? 9/30/2010 3:55 PM | Shawn

# Read Alot more

Gravatar MVVM with Prism 101 - Part 1: The Bootstrapper 9/12/2014 10:14 PM | Read Alot more

Comments have been closed on this topic.
 

 

Copyright © Mark J. Miller