Prism 4.0 First Drop is on CodePlex

Yesterday I posted about Prism 2.2’s release and said there would be a Prism 4.0 first drop soon. It happened sooner than I thought.

You can go grab the drop bits here:

http://compositewpf.codeplex.com/releases/view/46407

First a big thanks to the p&p Prism team for continuing the trend of getting bits out early and often to the community to drive the direction of what they produce. They’ve only been working on this a short time, and these QuickStarts are a great starting point that people can refer to already and provide feedback, as well as not having to wait a few more months for the finished product to come out.

The code that is in this drop is completely additive to what is in Prism 2.2, and is more of a very early look at some of the guidance that will ship with Prism 4 when it is done. Specifically, all that is there so far are two QuickStarts. One is an MVVM QuickStart that demonstrates the use of the MVVM pattern in a standalone Silverlight survey application that itself does not depend on Prism at all. The idea is to show the use of MVVM in a couple of its simplest forms – one being a top level view (composite view) that has its own view model that provides the state for the view, and the other being several dynamically generated views (through data templates) that each have their own instance of a view model supporting them.

The ViewModel QuickStart is not meant to say this is the only way to get it done. MVVM has many variations and flavors and ways of creating and relating the views and view models. But this QuickStart is really to help those who are pretty new to the pattern to see a running application that has one of the primary ways of structuring MVVM for this scenario, as well as to see the nature of some of the responsibilities and things that a ViewModel is supposed to do for a view.

6-3-2010 2-56-42 PM

Some of the things the ViewModels in the QuickStart do that are normal responsibilities of a ViewModel:

  • Mapping of data from the model into the ViewModel properties so that it is readily available to the view in the form the view needs it without having to couple the view to the model itself or do conversions in the view to display the model data
  • Type or value conversions from the model to the view so the view doesn’t have to do those conversions
  • Validation logic that is specific to the presentation (i.e. max input length exceeded) and that does not or should not be part of the model
  • Exposing properties that are not part of the model themselves (i.e. character count remaining based on current input)
  • Invoking validation logic that does reside on the model itself

Right now the code does not have as liberal of comments as it should be the time it is done to explain some of the choices being made and why they are there in the ViewModel classes. But realize this is just a first early drop to start sharing the work in progress and get feedback.

The second QuickStart that is in this drop is a modularity QuickStart that shows the changing out MEF as the dependency injection container instead of using Unity. MEF has its own programming model for indicating dependencies through imports and offering up types through Export. What this QuickStart does is adds a MEFExtensions library that is structured very much like the UnityExtensions library in Prism 2.2 and prior. This library provides the Service Locator pattern-based bridge between the rest of the Prism code and the particular dependency injection container you choose to use. Prism remains container agnostic and allows you to choose from the built-in implementation for Unity, now adding an implementation for MEF, or you can write your own Service Locator bridge for other containers as well.

What I like about what they have done is that the code for the core Prism parts of your application look virtually identical to how they would look if you were (or are already) using Unity.

Instead of using the UnityBootstrapper base class for your own application Boostrapper, if you want to use MEF, you’ll just change out and use MefBootstrapper. The base class provides the same overrides (plus one new one for InitializeShell that gives you the same two-phase construction option that you have for the container and modules as well), so a lot of what you would normally put in your bootstrapper will look exactly the same, modulo those things that touch the container directly. Instead of registering and resolving types against the Unity container, you would be manipulating MEF catalogs to add types that are not automatically discovered, and could SatisfyImports to get instances of parts out of the container if they were going to be used directly in the bootstrapper.

The main differences in your module classes are that they will use MEF constructs to indicate their dependencies and to export their type and or contract to the MEF container. The QuickStart defines a strongly typed ModuleExport attribute for modules so they can provide metadata about their name and dependencies:



[ModuleExport(typeof(ModuleD))] publicclass ModuleD : IModule { private IModuleTracker moduleTracker; [ImportingConstructor] public ModuleD(IModuleTracker moduleTracker) { this.moduleTracker = moduleTracker; ... } publicvoid Initialize() { ... } }



You can of course also use property imports with the Import attribute in lieu of or in addition to ImportingConstructor, although I still favor constructor injection so that the dependency is available in the constructor for use.

For your Views, ViewModels, etc. they can just use standard MEF constructs, of which there are many good examples out there.

Here is a quick look at what the modularity QuickStart looks like:



6-3-2010 2-51-46 PM

It demonstrates loading of modules at startup, on-demand, based on references, directory scan, and configuration all in one quickstart instead of in separate ones like existing Prism QuickStarts. But it removes any other aspects of Prism such as regions and commands from the mix.

Even though there is a Silverlight version in the drop, it doesn’t currently work, so we will have to wait for the next drop to see what it looks like for XAP loading as modules. But the code will be very similar.

If you want to play with the bits and get in on the discussion and feedback, I’d encourage you to jump into the discussion forum on the CodePlex site. I’m also working closely with the team as an advisor, so you can also contact me directly (@briannoyes on twitter for quick contact).