David Hill's WebLog : Patterns and Practices

The Breadcrumb Navigation Pattern

dphill — Thu, 15 Oct 2009 22:16:34 GMT

The Breadcrumb Navigation pattern provides a visual representation of the path the user took as they navigated to a particular state in an application. It provides context so the user can see where they are logically within the application structure, and it allows them to quickly navigate that structure by jumping straight to previous breadcrumbs.

Perhaps the most common example of the breadcrumb navigation pattern is Windows Explorer – as you navigate the file system, the breadcrumb control at the top of window displays the path to the current folder, with each folder in the chain displayed as a button. You can jump directly to any of the parent folders by clicking on it.

You often see the pattern used in web sites, especially ones where the user is navigating through a lot of hierarchical data. For example, a lot of ecommerce site allows the user to browse the product catalog by drilling into product categories and by specifying search criteria and filters. Here’s a good example from GuitarCenter.com – you can navigate around within the product catalog by product category and filter the view by price or manufacturer.

The Breadcrumb Navigation Pattern in Helix

This post describes how you can implement the breadcrumb navigation pattern in Helix, my prototype navigation framework for Silverlight. You can download the latest version of Helix from here, and run the sample described below here.

The BreadcrumbBar Control

Implementing the Breadcrumb Navigation pattern in Helix turned out to be quite straightforward. The main element is the BreadcrumbBar control. This control displays the breadcrumbs as the user navigates within an associated Frame. The user can click on any of the breadcrumbs causing the associated Frame to navigate back to the corresponding point in the navigation history.

The BreadcrumbBar control is actually a sub-classed and re-templated ListBox control that is bound to the target Frame's journal. As the user navigates between Pages in the target Frame, journal entries are added to the journal. Each journal entry is represented in the BreadcrumbBar control as a ListBox item. The BreadcrumbBar control's template displays each item horizontally as a chevron, along with the corresponding page title. The most difficult part to getting this to work is the control template itself. I used Blend 3.0 to edit the template so even that wasn't that difficult. I also made a couple of changes to the Helix library itself to support breadcrumb style navigation in the Journal. More details on this below.

The Sample Application

Patterns & practices guidance is organized by four high-level focus areas – Fundamentals, Client, Server and Services. Within each area there can be a number of sub-categories (such as security, performance, etc), and within sub-categories there is the guidance itself. Since the catalog is hierarchical, it’s a natural fit for the breadcrumb navigation pattern. I’ll describe a simple application that uses the BreadcrumbBar control and Helix to allow the user to browse through the patterns & practices guidance catalog. You can see the completed application and the BreadcrumbBar control in action here.

This is a simple application that has a simple shell that contains a BreadCrumbBar control and a Frame control in a grid:

<BreadcrumbBar Grid.Row="1"

       NavigationTarget="{Binding ElementName=frame}"

       ClearForwardStack="False"/>

<Frame x:Name="frame" Grid.Row="2"

    NavigationUIVisibility="Hidden" InitialUri="HomePage"/>

The BreadcrumbBar control is connected to the target Frame through simple data binding. Since we’re using the BreadcrumbBar control we don’t need the Frame’s back/forward buttons so we can hide the Frame’s navigation UI. The Frame navigates to the HomePage on startup. That’s pretty much it. I’ll talk about the ClearForwardStack below. You can tweak some of the visual aspects of the BreadcrumbBar control, or even replace the control template, to suit your application’s UI style.

How Does It Work?

The BreadcrumbBar control is just a sub-classed and re-templated ListBox. When the NavigationTarget property value is set, it sets the base class ItemSource to the journal back stack.

this.ItemsSource = NavigationTarget.Journal.BackStack;

If the user changes the current selection (i.e. by clicking on a previous breadcrumb), the target Frame is navigated to the associated Uri. To support this I added two new methods to the IJournal interface – GoBackTo and GoForwardTo. These two methods allow the journal to navigate directly to an entry that’s in the back stack or the forward stack, without having to navigate backwards or forwards multiple times.

NavigationTarget.Journal.GoBackTo( entry, ClearForwardStack );

Two other things to note:

The current selection of the underlying ListBox tracks the last entry in the journal. In other words, as the user navigates to new pages within the Frame, a journal entry for it is added and it becomes the current selection in the BreadcrumbBar control.
The ClearForwardStack parameter is used to control how the journal’s forward stack is affected when the user clicks on a previous breadcrumb. Most often you’ll want the forward stack to be cleared, and this is the default. Sometimes you might want to keep the forward stack intact so the user can go forward again. To enable this, just set the ClearForwardStack parameter to false.

What’s Next For Helix?

Now that Silverlight 3.0 supports navigation, the need for Helix is not as great as it was. I actually wrote the original specs for the Silverlight 3.0 Navigation feature. The original design in fact was very similar to Helix, but due to a number of constraints the design evolved and became a little less extensible than originally planned. There are key extensibility points that Helix provides which enable a whole host of interesting scenarios that are difficult or impossible to achieve with the current Silverlight navigation implementation. I’ve really only scraped the surface of these in this series so I’ll continue to evolve Helix in order to explore these scenarios. I’m working with the Silverlight team to explore ways in which these key extensibility points can be opened up in upcoming Silverlight releases.

In the meantime, if you’re building a Silverlight application that requires navigation functionality, you should use the Silverlight 3.0 navigation framework since it’s robust and fully supported. Hopefully, the need for Helix will go away altogether once the Silverlight navigation framework is more extensible.

The Application Architecture Guide 2.0 Is Here!

dphill — Wed, 14 Oct 2009 17:13:29 GMT

The Application Architecture Guide 2^nd Edition is finally available! The complete guide is hosted on MSDN here. We’ve sent the guide off to MS Press for printing, so the printed version should be available from your favorite bookstore soon.

Since the final draft of guide was published on CodePlex early this year, we’ve been busy driving the guide through a final set of reviews and polishing the content. Based on community and p&p team feedback we’ve restructured the guide to make it easier to read and understand. We’ve also removed some of the duplication and made it easier to find your way around so you can more easily find the information that’s relevant to you. We’ve also incorporated a lot of the feedback that we’ve received from the community on topics like Domain Driven Design and Cloud Computing. It’s taken us a little longer than we thought, but we hope you’ll agree that the wait was worth it.

Of course, there are so many elements that go into producing a guide of this scope that it clearly represents a team effort. In particular, the many members of the community and the p&p team who brought their technical expertise and experience to the guide deserve a special mention, along with our esteemed writer Alex Homer and the rest of our content team who drove the guide through the edit, layout, indexing, and publishing phases.

What’s next for the guide? Well, that’s up to you! We designed the guide so that it could be more easily updated; for new architectural techniques and approaches, for new technologies, and for new application types and scenarios. For example, we could add a Windows Azure application archetype, or update the technology matrices for the .NET 4.0 wave of technologies. In order for us to prioritize where we go next with the guide we need your feedback, so please send it along and let us know what you think.

Prism Quick Start Kit Update

dphill — Mon, 15 Jun 2009 20:36:38 GMT

As promised, I have updated the Prism Quick Start Kit and added a WPF quick-start solution and WPF project templates. You can download the latest release here. In the zip you’ll find four project templates (Shell and Module templates for WPF and Silverlight) and two quick-start solutions, one each for WPF and Silverlight.

To install the templates, copy the project template zip files to your Visual Studio C# template folder. On my system the templates go here:

“My Documents\Visual Studio 2008\Templates\ProjectTemplates\Visual C#”

You should also remove the previous Prism templates if you have installed them. Next, register the templates with Visual Studio by running

devenv.exe /installvstemplates

in a Visual Studio command prompt window (as admin).

When you run Visual Studio and create a new project, you should see the four templates show up in the Visual C# node.

Using the Prism project templates should be pretty straightforward. Couple of things to note though:

When you create a project with any of these templates you should first of all update the references to point to the Prism assemblies on your system. The quick-start solutions come complete with a Lib folder that contains pre-built Prism binaries so they work out of the box for convenience, but you should try and use the Prism binaries on your system where you can.
You will of course need the Silverlight Visual Studio tools to be installed before you can use any of the Silverlight project templates or the quick-start solution. See here for more information on getting started with Silverlight development.
The WPF shell project comes complete with a module catalog that looks for modules in the local output folder. If you add a WPF module to your project you will have to copy the output module assembly to the shell’s bin/Debug or bin/Release folder. I use a post-build step on each module project to automatically copy the assemblies over after every build:

You’ll need to update this with the name of your shell project. You can achieve the same thing by simply adding project reference to your modules projects and then Visual Studio will copy over the assemblies for you, but since Prism advocates a loosely-coupled composite architecture this seems like cheating to me :-).

The Silverlight and WPF quick-start solutions are essentially the same – the only difference between the two is that the WPF shell includes a menu-like button that’s hooked up the shell’s Exit command. I also updated the quick-start solutions to include a style that can be applied to ContentControl regions so that a banner containing the region name is displayed. This is just to make it easier for folks to see where each region is located within the shell.

The quick-start solutions are meant to provide a skeletal solution on which you can build real application. They are not very interesting as a standalone app, but if you’re curious to see what it looks like you can run the Silverlight version of the quick-start solution here.

Prism Quick Start Kit

dphill — Sat, 30 May 2009 02:59:00 GMT

Building applications from scratch starting from a blank page or screen in Visual Studio is a frustrating, time consuming and intimidating task. Instead, most developers like to start with a working application that they can modify, tweak and extend to suit their needs.

Far too often though, developers take a demo or a sample as the starting point for their application, and this often leads to a poor application design that’s complex, difficult to test and debug, and inflexible. Demos and samples have their place of course – they are great for illustrating a single concept or a cool new feature – but they are typically not designed to provide a solid base for an entire application.

Prism is a library of design patterns that work together to provide a solid architectural foundation on which you can build real-world Silverlight and WPF applications that are flexible and maintainable. Some of the patterns that Prism contains are fairly simple while others are more complex, but they are designed to work together to solve some of the challenges you face when building these real-world applications.

We illustrate individual patterns using what we call ‘Quick-Starts’ which are small focused sample applications. We illustrate how the patterns work together using what we call a ‘Reference Implementation’, which is a large sample application that implements a real-world scenario (during development, we actually use the RI to help us figure out what challenges a developer faces when building a non-trivial real-world application, and from those challenges we distil the patterns that help to address them and then implement those patterns in a reusable library). For Prism, the RI is a Stock Trader application that allows you buy and sell stocks and to manage your portfolio.

However, neither the Quick-Starts nor the Reference Implementation that we include in Prism are great for taking as a starting point for a new Prism application. The Quick-Starts are too fine-grained and focused on one specific pattern or technique, while the Reference Implementation is too coarse-grained and includes a lot of application logic that’s specific to the stock trader scenario.

The Prism Quick Start Kit

To help with this problem, we are considering building a number of solution and project templates for Visual Studio that would give you a simple working app that you could tweak and modify. These would fall somewhere in-between the Quick-Starts and Reference Implementation and provide a basic solution and project structure into which you could add your application specific files.

I spent a couple of days this week prototyping this approach. I built a couple of project templates (one for a Prism Shell, and one for a Prism Module) and a solution template that provide a complete multi-module working app. You can download these templates from here. Together, these templates make up what I call the ‘Prism Quick Start Kit’.

Installation

Installation of the project templates is fairly straightforward:

Unzip the starter kit and copy the ‘Prism Shell.zip’ and ‘Prism Module.zip’ files into your Visual Studio templates folder. They are C# templates so they go here on my system:

My Documents\Visual Studio 2008\Templates\ProjectTemplates\Visual C#
To get Visual Studio to display the new project templates in the New Projects dialog, run the following command (as admin) in a Visual Studio Command Prompt window:

devenv.exe /installvstemplates

Getting Started With The Prism Project Templates

To see the project templates in action, follow these steps:

Fire up Visual Studio, and click File/New/Web Site. Click on ASP.NET Web Site and enter ‘PrismApp’ as the folder name. This will create the web project that will host our Prism application.
Next, right click on the PrismApp solution and selected Add/New Project. Select the ‘Visual C#’ project types node and you should see the Prism Shell and Prism Module templates in the My Templates section:
Click on the Prism Shell template and then click on OK. This will create a Prism Shell project called ‘Prism.Shell1’.
We need to tidy up the project references to point to the Prism and Unity assemblies. If you click on the References node you’ll probably see that these references need updating. If you’ve added these assemblies into your GAC then they should be ok, but if not, you’ll need to remove them and add them again by browsing to wherever you complied them on your system.
Next, we need to link the Prism Shell project to the Web project. Right click on the web project and select Property Pages. Click on the Silverlight Applications node and then click the Add button. In the dialog, select the Prism Shell project and click Add then OK.
This will link the Prism Shell project to the web project and create a test page. Right click on the Prism.Shell1TestPage.html page and select Set As Start Page. Press F5 and click Ok to enable debugging. You should see the Prism shell in all its glory:
The shell includes all of the basic things you typically need in a shell – a shell View and ViewModel, a bootstrapper and a module catalog. The shell’s UI includes a simple 3 region layout. [Eventually, you can imagine having a whole gallery of different shell layouts and themes to choose from…]
The next step is to create a Prism module project. Right click on the PrismApp solution, select Add/New Project, choose the Prism Module project template and click OK. This will create a module project called ‘Prism.Module1’. The project template contains all of the basic things you need in a module – a View and ViewModel, a basic data model and a data service.
We need to do the dance with the references as above. [We’ll hopefully figure out a way to make this experience much better in the future…]
Next, link the module project with the web project as above, but this time make sure that the ‘Add a test page’ check box is unchecked – we don’t need a test page for the module. Click Add then OK. This step ensures that the module’s xap file gets copied to the web ClientBin folder.
The last step is to add the module to the shell’s module catalog. Open the ModuleCatalog.xaml file and uncomment the first entry:

<prism:ModuleInfo Ref="Prism.Module1.xap"

  ModuleName="Module1"

  ModuleType="Prism.Module1.ModuleInit, Prism.Module1, Version=1.0.0.0"

  InitializationMode="WhenAvailable"/>

If you used a different name for the module, you’ll have to edit this to use the names that you chose.

When you press F5, you will see the module get loaded into the shell and the module’s view displayed in the shell’s main region. You’ll also notice that the module includes a simple data model that gives the UI something to display. You can take this as a starting point and modify to suit your needs.

The Prism Quick Start Solution

I find the project templates described above pretty useful for creating new Prism projects, but there are way too many steps involved to make it a simple and clean experience. What I’d really like to do is to create a ‘Solution Template’ that includes all of the sub-projects and references all linked up and ready to go.

Unfortunately Visual Studio doesn’t by itself allow this to be done easily. There are additional tools and frameworks available that enable this, but at this stage I wanted to keep it simple so the next best thing was to just create a baseline sample project that I can manually copy and modify whenever I want to build a Prism multi-module solution. I call this the ‘Prism Quick-Start Solution’.

The baseline quick-start solution is the third zip file in the Prism quick-start kit. If you unzip it you’ll see that it contains Web and Shell projects, two Module projects and a ‘Common’ class library. The solution has all of these linked together and includes the Prism and Unity assembly so that you don’t have to fix up any references. In other words, you can unzip it and go!

If you run the app or examine the code, you’ll see that it contains a little more functionality than you get by just using the project templates described above. This is because, in a typical Prism application, there are a couple of common things that you need to do to coordinate the functionality between the Shell and the multiple Modules.

An example of this is when you implement loosely-coupled events between modules to coordinate context or user actions. The quick-start solution shows how to implement simple cross-module master-detail functionality – when you click on the Master View (from Module 1), the Catalog View (from Module 2) will update. This also shows how you typically coordinate data and context across two modules…

Another example is the use of a Controller class to programmatically coordinate the display of Views in a region in order to implement navigation or application workflow. The quick-start solution uses a controller class to programmatically display views in the main region when the user clicks on buttons in the master view.

The quick-start solution is meant to provide a basic structure for a Prism app and to include the most commonly used features of Prism. I find it very useful as a starting point because it contains all of the little code snippets and that you often need and has a basic structure in place making it pretty straightforward to take it and modify it to create many different types of applications. It’s hopefully also a good place to experiment with Prism and to learn about some of its basic features.

oO------Oo

I hope you find these templates useful. We’re hoping to provide templates like these in Prism 3.0 but we’d also like to provide item templates, code snippets and some simple in-tool automation to make building Prism apps really simple and straightforward. Let me know what you think, and whatever else you’d like to see in Prism 3.0…

Download the Prism Quick Start Kit here.

ViewModel and Dependency Injection

dphill — Mon, 18 May 2009 22:28:23 GMT

In my last post – Silverlight Navigation Part 3 – I outlined a mechanism whereby you could navigate to a View and have the application create and wire up the associated ViewModel automatically. I also showed the inverse of this, where you could navigate to a ViewModel and have the application automatically create and wire up the associated View automatically.

Whether you prefer the View-First or the ViewModel-First approach, the essential feature that really supports the ViewModel pattern is that the system should be able to create a ViewModel for a View (or vice versa) automatically. Otherwise, the burden falls to the developer to do this in code, which can result in a complicated architecture that’s either inflexible or difficult to understand and maintain.

Let’s say, for example, that you have adopted a View-First approach. Now, you could just have some code in your application (say, in a controller component or event handler somewhere) that simply creates the required View and it’s associated ViewModel and wires them together like this:

public ShowCustomer()

    CustomerView view = new CustomerView();

    CustomerViewModel viewModel = new CustomerViewModel();

    view.DataContext = viewModel;

    myContentControl.Content = view;

You can use this approach with a ViewModel-First approach too. Another simple approach is to just get the View to create its own ViewModel, either in its constructor:

public partial class CustomerView : UserControl

    public CustomerView()

        InitializeComponent();

        this.DataContext = new CustomerViewModel();

or via XAML:

<UserControl.DataContext>

    <CustomerViewModel />

</UserControl.DataContext>

All three of these approaches work great, except that they hard code your application to use specific View and ViewModel types. This may very well not be an issue for you, and if it isn’t, I say go for it!

However, there are times when you’ll want to have the View and the ViewModel types more loosely coupled. An example might be when you want to decide at run-time which View to display for a particular ViewModel based on, say, the user’s role, chosen UI theme, screen size, or even the type of device that the user is using(!). So, while the approaches above are simple, they are relatively inflexible.

Dependency Injection To The Rescue?

It is at this point that the Dependency Injection folks will start to gesticulate wildly and remind us that this is exactly the situation in which DI excels. Remember that with DI, if you have a dependency between one class and another, the system (i.e. the DI container) can automatically fulfill that dependency dynamically at run-time for you. This allows the classes to be more loosely coupled and removes the need for you to manage the creation of dependent classes yourself. Let’s see how this works…

Say we have a class ‘A’ that depends on (i.e. has a reference to) a class ‘B’. Typical DI containers (including Unity) require that we express the dependency between A and B using a type – typically (but not necessarily) an intermediate interface type, say IB – and that we define a constructor on A that takes a reference to that type. We then register our implementation of the intermediate interface type with the container – so that it knows that whenever anybody wants an implementation of IB it will create an instance of B.

So, when we want an instance of class A, we just ask the container to create one for us. It spots that class A requires a reference to an IB implementation, so it goes and creates a B for us automatically and passes a reference to it to A’s constructor. The container manages the creation of dependent classes for us!

It is of course true that in many situations DI is a good solution for this kind of problem. I think though, that for the ViewModel scenario DI is not ideal. To illustrate why, let’s see how DI typically works in View-First and ViewModel-First scenarios…

The Perils of IViewModel

In our View-First example above, we have a View that wants a reference to (depends on) a ViewModel, so we’d first register an implementation of our ViewModel with the container:

_container.RegisterType<ICustomerViewModel, CustomerViewModel>();

and we’d design the View so that it gets a reference to the ViewModel implementation in its constructor:

public CustomerView( ICustomerViewModel viewModel )

    this.DataContex = viewModel;

Finally, we’d get the container to create an instance of the View. The container will automatically create an instance of the registered ViewModel type and pass a reference to it into the View’s constructor.

CustomerView view = _container.Resolve<CustomerView>();

Ok this works, but I think there are a number of problems with this approach:

To create the View we have to use the DI container. We can’t just create the View using ‘new’ and we can’t create it declaratively via XAML (since that will use the default constructor which won’t pass in a reference to the required ViewModel). In other words, we have to have a controller or event handler or some code somewhere that creates the View via the container by calling Resolve.
The UI designer (even if the UI designer is really a developer) should not have to write code in the View just to make it work. If there is some complicated UI behavior that can’t be done declaratively, then code may be required, but this should be a special case and not required every time just to get stuff wired up and working. Even implementing the simple constructor above takes some explanation and can be easily forgotten or incorrectly implemented.
We have defined a ‘marker’ interface type that we don’t really need – i.e. the interface has no properties or methods, we’re just using it as a marker. Yes, we could define some properties and method on it, but the View should not be programmatically calling into the ViewModel. Remember, UI designers should not have to write any code. All interactions between View and ViewModel should be done via bindings and attached behaviors so that the View is just a loosely coupled observer of the ViewModel.

The Evils of IView

So that’s Dependency Injection in a View-First world. What about a ViewModel-First world? Well, things are no better here either. Similar to the process outlined above, we’d probably define an IView interface; register an implementation of it with the container; define a constructor on the ViewModel that accepts an IView reference; then create an instance of the ViewModel using the container:

_container.RegisterType<ICustomerView, CustomerView>();

...

public CustomerViewModel( ICustomerView view )

    ((FrameworkElement)view).DataContext = this;

...

CustomerViewModel viewModel = _container.Resolve<CustomerViewModel>();

Again, a couple of problems with this approach:

Again, we can’t create a View declaratively using XAML – the container will create the View as a result of creating an instance of the ViewModel class – so we’d have to have a controller or event handler or some code somewhere to kick things off.
We’d have a marker interface that we’d don’t really need and that won’t define any properties or methods – the ViewModel should not be programmatically calling into a View.
The UI designer would have to implement an interface on the View each and every time they create one. It’s not terribly complicated, but the UI designer should not be required to write any code except for advanced scenarios.
The ViewModel-First approach is actually slightly worse that the View-First approach because of the nasty cast in the constructor. This is required in order to set the view’s data context to the ViewModel.

Wouldn’t It Be Nice If…

In my last post on navigation, I showed a couple of different approaches to the problem of conjuring up a View for a ViewModel (or vice versa) without using a Dependency Injection approach.

For View-First, instead of using DI and defining interfaces and constructors, I just used an attached property on the View to specify the type name of the ViewModel (ViewModel.TypeName) and the system automatically constructed the ViewModel for me and wired it up to the View’s DataContext.
Going the other way (ViewModel-First) , I just used a naming convention to infer the name of the View from the ViewModel’s type name, created an instance of that View and set it’s DataContext.

Neither of these approaches are ideal though, so I got to thinking what an ideal approach might look like… The key is that we need a simple way of expressing the relationship between the View and the ViewModel types so that the system can just make the right things happen!

If you’re familiar with DataTemplates in WPF, you know that it’s possible to define a DataTemplate (somewhere in the application’s resources) for a particular (non UI) type. Whenever the system has to display an object of that type, the DataTemplate is automatically used to visually represent it. Under the covers, the system creates an instance of the DataTemplate, sets its DataContext to the object that it represents, and then displays it in the UI. Silverlight does not yet support implicit data templating – you have to specify the DataTemplate explicitly for each control – but the mechanism is very similar.

I think this is close to what we want…

I think of DataTemplates simply as “Thin Views” – i.e. purely declarative Views with no code behind. They are very useful, but sometimes you just need to have some code in the View (for complex visual behavior that can’t be done declaratively). So, if the system could be extended to include Views that could have code behind, it would all fit together in a nice, simple, consistent model. It could look something like this…

We define a View as usual and simply declare that it is associated with a ViewModel data type:

<UserControl x:Class="MySample.CustomerView"

             DataType="{x:Type MySample.CustomerViewModel}"

For the ViewModel-First approach, we simple create (or navigate to) an instance of the ViewModel and display it. For example,

MyContentControl.Content = new CustomerViewModel();

The system would then step in and create an instance of the View that corresponds to this type and would wire up the DataContext for us – just like the system does today with DataTemplates!!!

Similarly, for View-First, where we simply create (or navigate to) a View, the system would automatically create an instance of the associated ViewModel type for us and wire up the DataContext. There would likely be another property to control this behavior.

I think this approach has a number of benefits:

The system carries the burden of finding and creating corresponding Views and ViewModels, making our application code much, much simpler. And simpler means that it’s faster to write, easier to debug, and easier to unit test!
It gives us a single consistent model that works for Views with and without code behind.
It works declaratively as well as programmatically giving us a lot of freedom to create Views or ViewModels in code or in XAML as desired. It works great with navigation too.
It allows Views to express a dependency on a particular ViewModel, while allowing ViewModels to remain completely View agnostic. This opens up a whole host of interesting design-time tooling possibilities – like you get with DataTemplates today – but with more explicit support for the ViewModel pattern. For example, you can imagine that the UI designers can provide intelli-sense or drag & drop support for binding expressions and behaviors (because the design-time system can determine the ViewModel’s commands, notifications and properties).

You’ll have noticed that we’re not using an intermediate interface type to loosely couple the View and ViewModel. The approach could be extended to support that though, for example by using the upcoming Managed Extensibility Framework (MEF), or by building in some form of simple Dependency Injection mechanism into the XAML loader system.

Until I prototype this approach more fully, it’s not clear whether it will really work as well as expected. Also, it’s not clear at this stage when (or if) we could expect it this approach to be implemented in the platform.

We can but dream though…

Prism 2.0 Refresh

dphill — Mon, 02 Mar 2009 03:17:28 GMT

We just posted a refresh to the Prism 2.0 bits. You can download the latest release from the same location on MSDN here.

The recent release of the GDR update to Silverlight 2.0 (which takes Silverlight from version 2.0.31005 to version 2.0.40115) causes a problem when building the Composite.Silverlight.Tests project. This issue only affects the unit tests and there is no change required to the core library or any of the quick-starts or the reference implementation. The issue was due to an incorrect path in one of the batch files in the unit test project. You can read more details on the issue here.

While we were refreshing the bits, we thought we'd also slip in a fix to a recently reported issue with view activation in tabbed regions. This issue caused a difference in behavior between Prism 1.0 and 2.0. You can read the details here. This issue has been fixed with the refreshed release.

We also just released a PDF version of the Prism 2.0 documentation so you can print it more easily. You can download the PDF file from here.

Coming Soon! We are working on Visual Basic versions of the quick-starts and documentation. I'll post more details once we've released these in the next week or so...

Prism 2.0 Is Live!

dphill — Sat, 21 Feb 2009 00:11:34 GMT

WooHoo! Prism 2.0 is done and is now live on MSDN! You can access the Prism 2.0 documentation here, and download the code from here.

Prism is a library of patterns that help you build robust, flexible and modular WPF and Silverlight applications. These patterns also support unit testing, separation of concerns, loose coupling and the ability to share application logic between Silverlight and WPF applications. The download includes the source code for the library itself, extensive documentation, a sample application that shows how the patterns work together in a real-world application, and a whole bunch of quick-starts and how-to's. There's even a snazzy Visual Studio add-in to help you easily share code between WPF and Silverlight.

The Prism team has been busy writing blogs and recording videos to get the word out...

Blaine Wastell (program manager extraordinaire for Prism) chats to Adam Kinney about Prism on Channel 9 here. He's even written a blog post on Prism here.

If you haven't had enough Blaine you can catch even more of him here on Channel 9, alongside Bob Brumfield (one of the developers of Prism), as Ajoy Krishnamoorthy (our product manager) ponders the eternal question - What is Prism? Ajoy's post on the release is here and Bob's is here.

Still hungry for more information on Prism?

Check out Erwin's post here, and Julian's post is here. Erwin and Julian were part of the super-talented Prism development team. Expect more videos and posts from the dev team on how to use the various super-cool features of Prism soon.

And last but by no means least, Prism's test lead Larry Brader has a post here. Larry's going to be delivering a whole series of posts that will tell you everything you ever wanted to know about unit testing and acceptance testing in WPF and Silverlight, so be sure to check his blog often.

Master-Detail With CollectionViewModel

dphill — Fri, 20 Feb 2009 00:47:31 GMT

Implementing a Master-Detail style UI with the CollectionViewModel I described in my previous post is pretty easy. With a selector control bound to a CollectionViewModel as shown in my previous post, you just need to add a content control to the View and bind its Content property to the current item and define how you want it to be rendered by defining a data template.

For the sample in my previous post the view's XAML contains this:

<ContentControl Content="{Binding Path=Catalog.CurrentItem}">

    <ContentControl.ContentTemplate>

        <DataTemplate>

...

        </DataTemplate>

    </ContentControl.ContentTemplate>

</ContentControl>

Note: In WPF, you strictly only need to bind the content control's Content property to the Catalog - WPF automatically binds to the Catalog's current item for you. Not sure why they did it this way. I think an explicit binding to the CurrentItem property is easier to understand, and I don't mind typing the extra characters. Sometimes a little more is definitely more :-)

You can run the updated sample here and download the updated source here. I also updated it to use the final release assemblies from Prism 2.0, and fixed a glitch in the Silverlight Unit Testing assembly references...

The ViewModel Pattern

dphill — Sun, 01 Feb 2009 02:08:02 GMT

The ViewModel pattern (more formally called the Model-View-ViewModel pattern, but that’s way too long winded and I’m lazy) is an increasingly popular pattern with WPF and Silverlight developers. This is largely due to its simplicity and flexibility and its inherent support in WPF and Silverlight. It helps to separate business, presentation and UI logic which in turn helps with a whole host of development and design issues.

Having a clean separation between your application’s user interface and underlying application logic means that you can unit test it independently of the user interface. Automated testing of application logic through the UI can be complex and time consuming to setup. In addition, it can be difficult to isolate errors in the user interface or application logic portions of your application when they are both tested at the same time.

Another key benefit of using the ViewModel pattern is that it allows application developers to focus on application logic while user interface designers can focus on the visual aspects of the application. This allows the look and feel of the application to be defined separately from the underlying application logic, making it easier to maintain, modify (say as a result of usability feedback) or to customize.

The ViewModel pattern also makes the application easier to understand and maintain. It also provides more opportunities for code re-use, allowing application logic to be re-used in different parts of the same application, or allowing the user interface to be tailored to specific user roles or locales, or allowing application logic to be shared between desktop and RIA versions of the same application. In all of these cases, the underlying application logic is the same though its visual representation may be quite different.

Variations On A Theme

There are many posts and articles out there that describe the ViewModel pattern (my favorite ones are listed at the end of this post), and they all seem to differ slightly in how they define or describe the pattern. This is, of course, totally reasonable. Patterns are just a way to describe a potential solution to a design problem and specific scenarios will call for a pattern to be modified to best suit the situation. I find the (invariably heated) debates that the so-called 'design pattern experts' engage in as they argue about the finer details of a pattern to be, let’s just say, tedious and unhelpful. What matters is that the spirit and the underlying principles of the pattern are understood and applied - the details don't matter nearly as much.

The ViewModel pattern is just one of many patterns that fall into the 'Separated Presentation Pattern' bucket. Essentially, the ViewModel pattern is a variation of the Presentation Model pattern (actually, some would say that the ViewModel pattern it is in fact the same as the Presentation Model pattern). Whatever your point of view, I'm going to describe what I believe are the essential features of the pattern. In my next post I'll show you some code that I've been playing with recently that applies the ViewModel pattern to collection-based models.

ViewModel In A Nutshell

So what are the essential features of the ViewModel pattern? I describe the ViewModel pattern like this:

In the ViewModel pattern, the UI and any UI logic are encapsulated in a View. The View observes a ViewModel which encapsulates presentation logic and state. The ViewModel in turn interacts with the Model and acts as an intermediary between it and the View.

All of the separated presentation patterns exist to help separate UI from application logic by placing the various flavors of application logic and the UI into distinct classes or components. The differences between the various patterns are largely due to two things: the roles and responsibilities assigned to these classes, and how these classes interact with each other. Let’s look at the ViewModel pattern in these two respects:

Roles & Responsibilities

The roles and responsibilities of the classes in the ViewModel pattern can be characterized like this:

The ViewModel encapsulates presentation logic and state. Presentation logic is defined here as the application logic that is concerned with the application’s use-cases (or user stories, user tasks, workflow, etc) and defines the logical behavior and structure of the application. The ViewModel is NOT a control’s code behind. Presentation logic should have no idea what its visual representation will be like and should be independent of any specific user interface implementation. To maximize re-use opportunities, the ViewModel should have no reference to any specific UI classes, elements, controls or behavior (like animations). It should not derive from any UI base class (ideally it should be a POCO). It should (of course!) be unit testable and be able to function without any UI at all.
The Model encapsulates business logic and data. Business logic is defined here as any application logic that is concerned with the retrieval and management of application data and for making sure that any business rules that ensure data consistency and validity are imposed. To maximize re-use opportunities, Models should not contain any use-case or user-story specific behavior or application logic.
The View encapsulates UI and UI logic. Views define the specific user interface for a piece of the application. Views are typically just controls that are designed to work well when bound to a ViewModel. Their specific role is to present the user with a user interface that represents the application’s underlying data and logic in the most appropriate way, and to interpret user input gestures and forward them to the ViewModel that then defines how they affect the underlying data and application state in the Model. In some cases the view may contain UI logic – application logic that is specific to the user interface implementation – in the view’s code-behind file. However, such UI specific code is difficult to test and should be avoided as much as possible. Of course, there will be times when the View will have specific behavior that cannot be expressed declaratively in XAML so there may be some code in the View's code-behind, but this code should be specifically focused on managing the UI controls in the View and should not implement presentation logic.

Interactions

The next thing to consider is how they interact with each other. The key here is to understand the two-way interaction between the View and the ViewModel. I think the essential feature of the ViewModel pattern is that the View is an observer of the ViewModel, which means that the ViewModel doesn't have a direct reference to the View. The ViewModel acts like a state machine and the View's responsibility is to render the state in whatever way is appropriate, and to influence that state by interpreting user input gestures.

The View typically extracts state from the ViewModel through properties that the ViewModel provides and changes of state in the ViewModel are communicated through events and notifications that the View consumes. In the other direction, the View captures user input gestures and interacts with the ViewModel to change its state. This can happen in a number of ways. The View can simply set a value on a property provided by the ViewModel. More complex state changes can be achieved through action methods that are exposed by the ViewModel.

The ViewModel Pattern in WPF and Silverlight

You may have noticed that in the description of the ViewModel pattern above I don't make any mention of any specific WPF or Silverlight frameworks features. This is intentional since a pattern should be technology agnostic. Most of the posts and articles that describe the ViewModel pattern focus on the specific features of WPF and Silverlight that directly support the ViewModel pattern. In fact, these features do such a great job of supporting the ViewModel pattern that it becomes difficult to separate them from the pattern itself.

Let’s look at some of these features and see how they support the ViewModel pattern...

Data Binding: WPF and Silverlight data binding make it easy to bind a View to a ViewModel. Data bindings can be defined declaratively in XAML and are very flexible – you can pretty much bind anything to anything. The View’s DataContext references the ViewModel so that the View’s data bindings resolve to its properties and events. Two way data binding takes care of retrieving state from the ViewModel for presentation in the View, and for updating state in the ViewModel as a result of the user’s interaction with the UI. Change notifications fired by the ViewModel allow the view to be automatically updated whenever the ViewModel’s state changes.

Commands: While data binding provides a great mechanism for supporting two-way interaction between the View and the ViewModel for state exposed as properties, the ViewModel will often provide methods that represent actions that the user can initiate through the UI – submit an order, approve an expense report, etc. Commands provide a good solution for this. They allow controls in the View to be easily associated with actions that the user can carry out without requiring any UI logic glue code, and they allow the visual representation of the action (i.e. the UI) to be cleanly separated from the actual implementation of the command (i.e. the handler). WPF has much more extensive support for commands than WPF, but the basic mechanism can be used to allow a View and a ViewModel to interact cleanly.

Data Templates: The Data Template feature of WPF and Silverlight allow you to define a View entirely declaratively. This is great for Views that require no UI logic (no code behind) and are ‘pure’ UI. Data templates contain controls and their associated bindings. When a template is applied, its DataContext is set to the object that it's templating (in our case, the ViewModel) and the bindings take over. Data Templates allow you to focus on the presentation logic in the ViewModel and leave the ‘skinning’ of your ViewModel to a UI designer who can use a tool such as Blend to built the template without having to write any code whatsoever. WPF supports implicit data templates so you can associate a data template with a ViewModel type and wherever the system sees a ViewModel of that type, the data template will automatically get applied. Silverlight doesn’t yet support implicit data templates, but you can manually specify the data template for individual controls. Finally, WPF Data Template Selectors allow the system to choose a data template based on custom logic, say to account for user roles or location.

CollectionViews: I think WPF’s CollectionViews are actually good examples of ViewModels. They specifically support models that are collection based and they encapsulate presentation logic and state to support filtering, sorting, grouping and selection. They are easily consumed by Views through data binding, are independent of the UI and support unit testing. Silverlight doesn’t yet have as much support in this area, but it does provide the ICollectionView interface so you can implement something equivalent (this is the subject of my next post so stay tuned!!).

There are many other features in WPF and Silverlight – such as Styles, Visual State Manager, Triggers*, etc – that indirectly support the ViewModel pattern but the ones described above are the big ones. All of these features work together to help the View interact cleanly with the ViewModel. By ‘cleanly’ I specifically mean that they reduce the amount of UI specific code that is required to glue everything together.

* As a side note, I am not a big fan of triggers. They are very useful in some situations for defining visual behavior, but they can also be (mis-)used to define presentation logic in the view which is bad. I find the Visual State Manager a much better mechanism for defining visual behavior…

The Right Code in the Right Place

To summarize, getting the right code in the right place is the key to leveraging the ViewModel pattern to build flexible, robust WPF and Silverlight applications. Deciding where a specific piece of code should go can sometimes be difficult, but it gets easier with practice and the features that WPF and Silverlight provides help simplify this process dramatically.

More Stuff On ViewModel

Here’s a short of list posts and articles on the web that I’ve found the most useful and interesting

John Gossman's - the ‘father’ of the ViewModel pattern: http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx
Excellent article by Josh Smith in MSDN magazine: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Karl Shifflet and Adam Kinney talk about ViewModel on Channel9: http://channel9.msdn.com/shows/Continuum/MVVM/
Jeff Handley has a number of great post on ViewModel: http://blog.jeffhandley.com/archive/2008/10/21/viewmodel-pattern.aspx

oO------Oo

For those of you who are keenly awaiting my next post on navigation in Silverlight, this post and my previous post on view-first and presenter-first composition are really parts 2a and 2b of that series. I’ll be building on the concepts that I’ve described in these posts and focusing specifically on how navigation and the ViewModel pattern interact. Sorry it’s taken so long, but hopefully it’ll be worth the wait :-)

UI Composition Patterns

dphill — Sat, 06 Dec 2008 01:23:00 GMT

Figuring out the right name for something is one of the hardest things in software development. There is a lot to a name – the name conveys the concept; get the wrong name and you convey the wrong concept, leading to much confusion, developer irritation and mental pain.

We’re currently working on a new capability in Prism 2.0 that we’ve been calling ‘top-down’ or ‘view-first’ composition. We’re not really sure whether either of those specific names clearly and succinctly describes what this capability is all about, and so we’ve been having many discussions on the team about what it is exactly that top-down/view-first composition achieves and how it relates to other types of composition. If we can be really clear on those two things, then maybe we can figure out what the best name for it is. In this post I’ll describe what top-down/view-first composition is and how it relates to other types of composition. At the end I hope you’ll agree that ‘view-first’ is a reasonably good name for it. But, if you can think of a more appropriate name we’d dearly love to hear it!

Let’s start by defining composition as simply taking a bunch of ‘things’ and combining them to build an application. Different composition patterns describe different ways of composing an application, either by using different ‘things’, or by using a different way of combining the ‘things’. As always in software development, there’s more than one way to skin a cat (apologies to any cats or cat lovers reading this blog) so it isn't surprising that there are different composition patterns, each with its own advantages and disadvantages. Perhaps the most commonly used composition pattern though is the traditional ‘forms and controls’ pattern. Let’s walk through this pattern first and then we can contrast and compare other composition patterns to it.

Forms And Controls

Ah, good old-fashioned forms and controls. Where would we be without forms and controls? They have been the staple diet of UI tier application developers forever (well maybe not forever, but an awfully long time).

Using this composition pattern the developer will build an application by creating a number of forms. On each form they’ll drop one or more visual controls. They’ll configure the controls by setting various properties and then add code to the form to ‘wire’ the child controls up and implement the form’s business logic. The developer will often build controls of their own, and these will often be fairly sophisticated app-specific composite controls that contain many child controls. In fact, since forms are really just specialized types of controls, we can just think of this whole approach as ‘Control-Based Composition’.

The app is essentially the hierarchical combination of all of the controls and the code that wires them together. In this composition pattern then, the ‘things’ are visual controls, and the application is composed by assembling visual controls into higher-level controls and linking them together with code. It’s easy to provide a visual tooling experience for constructing applications in this way, and it’s relatively easy to understand the internal structure of an application by following its visual structure.

Control-based composition is pretty much the default experience that you get in almost all current tools and visual development environments, including Visual Studio, Blend, etc. Developers have been generally happy with this approach over the years – it’s simple, visual and designer friendly – so what’s the problem? Well, there are two related drawbacks to this approach – what I’ll call ‘Tight Coupling’ and ‘Overlapping Concerns’. Let’s take a look at each of these:

Tight Coupling – Since the developer explicitly chooses the controls at design-time, they can very easily make their application tightly coupled and inflexible. By choosing specific controls and writing code against that specific set of controls, it’s very easy to introduce strong dependencies that are dispersed throughout the entire codebase. These dependencies can be very hard to manage and can limit re-use opportunities and lead to static, brittle, hard to maintain, almost impossible to extend applications. They can make it very difficult to extend or modify the application without requiring (sometimes substantial) code changes, recompilation, and re-deployment of the application.
Overlapping Concerns – Most control models (all of the ones that I know of anyway) tend to define controls as single classes, and the control encapsulates both its UI and its business or presentation logic within this one class. From the consumer’s point of view, the class has an API and they code against that in the form or containing control. WPF and Silverlight have added the (absolutely fantastic) ability to re-style or re-template controls, which can help separate the controls UI from its behavior, but the control is still one class. For generic low-level controls (like buttons, text boxes, etc) this works great since they contain no business or presentation logic (just control logic). But for app-specific controls or forms (like, say, a CustomerList or CustomerContacts control) the control will typically mix visual aspects (e.g. BackgroundColor) with business or presentation logic aspects (e.g. AddCustomer, AddOrder). This can make it very difficult to test any business or presentation logic within the control without having to use some kind of UI automation or manual acceptance testing.

Neither of these two issues are intractable. The tight coupling problem can be addressed by adopting patterns that introduce loose coupling and that help manage dependencies – like modularity and dependency injection, etc. Using these patterns tends to alter the way in which the ‘things’ get composed into an application, but they tend not to affect what those things are. In this post, we’re going to focus mainly on the problem of overlapping concerns. We’ll see that the patterns that are used to address this issue generally lead to a change in the ‘things’ from which the application is composed.

Separated Presentation Patterns

One of the most popular remedies to the overlapping concerns issue is the introduction of a Separated Presentation Pattern (such as Model-View-Presenter, Model-View-ViewModel, Supervising Controller, etc, etc). I’m not going to detail the many different separated presentation patterns you could use here – it’s a big and somewhat nuanced subject – but suffice it to say that regardless of the actual pattern you choose, they all are concerned with separating out the purely visual aspects of a control from the business or presentation logic by encapsulating each into separate classes. For simplicity, I’ll call the class that encapsulates the visual aspects the ‘View’ class, and the class that encapsulates the presentation logic the ‘Presenter’ class (yes, different patterns use different names for these two classes, but the net result is the same so bear with me).

The two key benefits of adopting a separated presentation pattern are that you can unit test the behavioral/logic aspects of the control without having to automate it through the UI or do manual acceptance testing, and that you can more easily change the UI of the application while keeping the business or presentation logic completely untouched. There are other distinct benefits too, like being able to have your developers (who are typically bad at UI design) focus on app logic, while your UI designers (who are typically bad at writing app-logic) focus on the look and feel of the application. Another benefit is that since the View and the underlying Presenters are loosely coupled, the app can be more flexible and dynamic and choose (based on, say, the user’s role, current task or preferences) how best to render the application’s UI while re-using the exact same underlying Presenter.

With View and Presenter classes in the mix, what happens to the composition pattern? This is where things get interesting since we now have more ‘things’ with which we can compose. Essentially, the developer can choose to compose the application in one of two basic ways:

Compose the application from the Presenters, and then have the corresponding Views somehow created and wired up.
Compose the application from the Views, and then have the corresponding Presenters somehow created and wired up.

Not surprisingly, I’m going to call the first one ‘Presenter-First’ composition, and the second one (you guessed it!) ‘View-First’ composition. These two patterns represent two points on a spectrum and its possible to use both patterns in the same application, or to use a hybrid pattern that combines features from both, depending on your requirements or preference. In the next couple of sections, I’ll drill into each of these and describe their respective advantages and disadvantages.

Presenter-First Composition

In the Presenter-First composition pattern, the ‘things’ are primarily Presenters, and conceptually the application is composed by assembling/wiring Presenters together. The Presenters then pull in the Views that they depend on which then get inserted into the app’s UI.

With Presenter-First composition, the process goes something like this:

The Presenter is created first.
The Presenter (or some other entity) then creates a View and connects it to the Presenter.
The View gets shown in the correct position in the UI.

There are many different ways of achieving each of these steps. Because of the variations that are possible at each of these steps, Presenter-First is really a general approach rather than just a single specific approach. Some variations to consider:

When a Presenter is created, its typically wired up to communicate with other Presenters (either in a peer-to-peer arrangement or in a parent-child arrangement) and with other Models and Services. Often, Dependency Injection is used to help create and wire up Presenters to other objects.
The Presenter itself can be responsible for explicitly creating a View for itself and then expose it through a property (e.g. MyPresenter.View). It’s not likely that the Presenter will create a specific View class – this would reduce flexibility and introduce tight coupling – it’s more likely that the Presenter will use a DI container or some form of configuration driven mechanism to create a suitable View. More often, the View creation mechanism is external to the Presenter and Views can be created implicitly (as is the case when using implicit DataTemplates in WPF) or explicitly by using a View factory of some sort that creates an instance of a specific View class according to some external configuration.
Once the View is created, it is ‘connected’ to the Presenter. I personally dislike any model where the Presenter has explicit knowledge of a View (say through an IView interface reference) regardless of how the View was created. I much prefer the model where the View is an observer of the Presenter and the Presenter goes about its business altering and managing its state, according to the presentation logic it encapsulates, and the View updates itself accordingly through bindings and behaviors. I’ll be posting much more on this in a later post…

To some developers, presenter-first composition feels more natural and ‘pure’ since the View creation can be abstracted away allowing them to focus on the logical non-UI structure (Presenters and other non-UI Models and Services) of the application. For any one particular use case or screen in the application, one or more presenters will be in play and the developer can write unit tests for this combination of presenters without having to test by automating through the UI. In extreme cases, the application may even be driven completely ‘headless’ and not require a UI at all, and be able to be driven through a command line interface (nice for the purists but not generally useful IMHO).

The downside with this approach is that it tends to be complex, making it very difficult to understand how the various pieces of the application get created and connected together. Since the UI is constructed at run-time as a result of the interaction of many components, to understand the structure of an application, you often have to spend many happy hours in the debugger tracing through everything and seeing what gets created, when and by whom. It also is very difficult to provide any kind of visual tooling experience for applications constructed in this way.

You can see this composition pattern in action in Prism 1.0 in the UIComposition quick-start. This example implements a simple project management application made up of 2 separate modules – an Employee module that provides general information on a list of employees, and a Projects module that provides details on their current projects. The Projects module has a ProjectsListPresenter, ProjectsListView and a ProjectService. A controller class, the EmployeesController class, is used to coordinate and stitch everything together.

When the user selects a particular employee in the UI, the EmployeesController constructs a Presenter using the container:

IProjectsListPresenter projectsListPresenter = this.container.Resolve<IProjectsListPresenter>();

The DI container constructs the Presenter class and injects any dependencies that it may have. In this case, the Presenter has dependencies on a ProjectsListView and a ProjectService. The container dutifully creates those objects and passes references to a them into the Presenter’s constructor.

public class ProjectsListPresenter : IProjectsListPresenter

    private readonly IProjectService projectService;

    public IProjectsListView View { get; set; }

    public ProjectsListPresenter( IProjectsListView view, IProjectService projectService )

        this.View = view;

        this.projectService = projectService;

Note that all of these types are registered with the container in the Projects module’s Initialize method so the container knows how to resolve everything:

this.container.RegisterType<IProjectService, ProjectService>();

this.container.RegisterType<IProjectsListView, ProjectsListView>();

this.container.RegisterType<IProjectsListPresenter, ProjectsListPresenter>();

Now, the astute reader might have spotted that in the code above, the View is technically constructed before the Presenter. That’s just an artifact of the fact that we’re using constructor injection in this example. The key thing is that the Presenter is logically created first, and that the Presenter has a dependency on the View (rather than the other way round).

With the Presenter and its dependent View and Service constructed and wired up, the controller needs to show the Presenter’s View in the UI somehow. To do this, we use Regions. Regions are essentially named placeholders in the UI into which arbitrary Views can be inserted. In the EmployeeDetailsView we defined a region called ‘DetailViewsRegion’:

<TabControl cal:RegionManager.RegionName="DetailViewsRegion" … >

This view is in the Employees module and doesn’t know anything about the specific ProjectListView that we want to show here. The controller is responsible for making this association. To do that it goes and looks for this region, using the region manager, and then inserts the view into it:

IRegion region = detailsRegionManager.Regions["DetailViewsRegion"];

region.Add( projectsListPresenter.View, "CurrentProjectsView" );

detailsRegion.Activate( detailsPresenter.View );

The Region is passive in the sense that it has no knowledge that any specific view (or any view at all) will be shown – it’s left to the presenter or controller to determine which, if any, view is shown and to inject that view into the region. This makes it somewhat difficult to understand the structure of the application just by looking at the UI because the placeholders are just passive named regions – in other words, the logical structure of the application can’t be easily determined from the visual structure. In addition, if a region required by module is not defined in the hosting application, the module may fail unless the developer checks for the existence of the region before trying to inject the View.

The following diagram shows the sequence of events for Presenter-First composition.

Because this approach focuses on creating and connecting the Presenters, Models, Services and other non-UI components first, and then creating Views and pushing them up into the UI second, we’ve also been calling this approach Bottom-Up Composition. I think Presenter-First is a more accurate name though…

View-First Composition

As its name implies, View-First Composition focuses on composing the application first and foremost from Views rather than Presenters – the ‘things’ are primarily Views – and conceptually the application is composed from Views. The Views then pull in the Presenters that they depend on.

With View-First composition, the process goes something like this:

The View is created first.
The View (or some other entity) then creates a Presenter and connects it to the View.
The View gets shown in the correct position in the UI.

Again, there are many different ways of achieving each of these steps and View-First is really a general approach to composition.

The principal difference between View-First and Presenter-First is that the View has a dependency on the Presenter, rather than the other way round. View-First is a composition pattern that lies somewhere between the traditional Control-Based composition and Presenter-First composition. One of its primary benefits is that it makes it easier to construct applications than with the Presenter-First approach, while retaining the loosely coupled, pluggable, unit-testable benefits of using a separated presentation pattern. This pattern also makes it much easier to understand the structure of a given application by allowing you to follow the visual structure, reducing the need to track code execution in order to understand how everything is created and connected together.

Let’s see View-First composition in action. We’ll use the same example as above and show how the same application would be composed using this approach.

Disclaimer! We’re still working on this so some of the code below is just an illustration of how this capability could work, and we may or may not implement it as shown here – your feedback would be great to have on this.

When the application runs, the EmployeeDetailsView is shown. As before, this view defines a region where the project list for the currently selected employee will be displayed.

<TabControl cal:RegionManager.RegionName="DetailViewsRegion" … >

Whereas in Presenter-First composition the region is passive and waits for a view to be injected into it by a controller, in View-First composition the region will proactively go and create any views that are registered to be shown in this region. When the EmployeeDetailsView is shown, the region manager will go and see if any views have been registered for the DetailViewsRegion. Views are registered with the region manager in the module’s Initialize method:

this.regionManager.RegisterViewForRegion( "DetailViewsRegion", typeof( ProjectsListView ) );

You can think of this as the equivalent of registering a type with a DI container so it will know how to instantiate dependencies, except here we’re registering a View type against a named region so the region manager will know how to instantiate the views required for that region. Note that the parent view and the child view are still loosely coupled and we can still plug in any implementation of a view that we choose.

The ProjectsListView is now instantiated by the RegionManager, but what about the Presenter? In View-First composition, the ProjectsListPresenter is considered a dependency of the view. This dependency is expressed in the ProjectsListView declaratively like this:

<UserControl x:Class="UIComposition.Modules.Project.ProjectsListView"

    cal:Presenter.Type="{x:Type UIComposition.Modules.Project.IProjectsListPresenter}" … >

After the view is created, an instance of the required presenter is created using the DI container, which incidentally will create in turn any dependencies that the Presenter has (in this case the ProjectService). Once the Presenter is created it is connected to the view by setting it as the view’s data context (so that any binding or command expressions in the view will be directed to the presenter).

The following diagram shows the sequence of events for View-First composition.

Since composition flows from the View down to the Presenters and then to the Models, Services and other non-UI components, we've been also been calling this 'Top-Down' composition. Again, I think View-First is probably a better name though.

And that’s pretty much it. With View-First composition, we have less code for the same end-result but the chief benefit is that it’s much easier to follow what happens and when. The key thing to remember is that the View is created first, then the Presenter (which is considered a dependency of the View) then any dependencies that the Presenter has. This pattern is very similar to the traditional and familiar control-based composition pattern, but with the added benefit that it’s loosely coupled and separates the UI from the business and presentation logic. It is also easy to see how this pattern can be supported by visual tools – imagine a placeholder control that you can drop onto your form and then configure to go and pull in whatever View is registered by the pluggable modules.

oO------Oo

Hopefully this all makes sense. Once you move away from control-based model where everything is in one class, to a separated presentation model which introduces additional classes, things can get complicated pretty quickly. These patterns can help make sense of this additional complexity and allow you to realize the benefits of loose coupling and a separation of concerns without imposing too much overhead...

Are We Firing On All Cylinders Or What?

dphill — Wed, 12 Nov 2008 17:59:40 GMT

This last month has been what you might call crazy.

Within the space of a couple of weeks we have had no less than 6 major releases in P&P! We're a fairly small team, but we follow an agile process for all of our projects which enables us to scale pretty well and have multiple projects in flight at any one time. This time, 6 of our projects were completed or hit key milestones at about the same time so we've had a flurry of releases in a short period. In no particular order:

EntLib 4.1 & Unity 1.2 - The latest release of our wildly popular Enterprise Library, with performance and usability improvements as well as a bunch of fixes and support for VS2008 SP1. Download it from MSDN here, or checkout the CodePlex site here.
Unity 1.2 - Our Dependency Injection Container. New features include the integration of policy injection so you can have the container manage interception. Download it from MSDN here, or check out the CodePlex community site here.
SharePoint Guidance - Guidance on how to develop SharePoint applications, including how to design for testability & unit testing, continuous integration, setting up different environments for development, build, test, staging, and production, and how to manage the application life cycle through development, test, deployment, and upgrading. Download it from MSDN here, checkout the CodePlex site here, or read about it on Blaine's blog.
Application Architecture Guide 2 (Beta 1) - The first beta of the next edition of our popular Application Architecture Guide. Visit the CodePlex site here, or download the PDF here.
Acceptance Testing Guidance (Beta 1) - Guidance on planning and executing acceptance tests and generally defining what 'done' really means. CodePlex site here, or download the guide directly from here.
Distributed Agile Development Whitepaper - Ade Miller's whitepaper on how to do agile development with a distributed team, based on P&P's own experiences. Download the PDF here and checkout the P&P Agile development showcase page here.

Plus, we've continued to make good progress on Prism, our guidance for building composite WPF and Silverlight applications, and we made our 5th drop on CodePlex here.

Not only that, but it's conference season too. We've had folks at the PDC in LA, Agile Development Practices in Orlando, our very own P&P Summit in Redmond, TechEd Europe in Barcelona, and next week it's the Strategic Architects Forum in San Francisco, and the P&P Roadshow in China soon after that. If only air miles were actually worth having...

Tales From The PDC - Day 1

dphill — Tue, 28 Oct 2008 03:45:13 GMT

Well here I am in sunny LA at the PDC. At least I assume it's sunny, not been outside all day. Been too busy 'capturing the brain power' or something...

No doubt by the time I post this you'll have heard something about Azure. Apart from being a rather nice shade of blue it's the name of the new Microsoft cloud platform. I was at the key note when Ray Ozzie announced Azure and went through the end-to-end Microsoft Software + Services strategy. I have a post in prep, but there was a lot of interesting stuff in the keynote so it's going to take a while to turn my notes into something coherent. And there's even more to come at tomorrow's keynote apparently...

Apart from the keynote I spent most of the day manning the P&P booth in the pavilion, but I did manage to catch one session this afternoon. Ian Ellison-Taylor (GM of WPF and Silverlight) did a session on "sharing skills and code between WPF and Silverlight", a topic that interests me and the Prism team a lot.

Well the room (and it was a big room) was standing room only, so I guess there is a lot of interest in this topic. Ian spent a couple of minutes talking about why we need both WPF and SL, the different scenarios that they address, and their different technical constraints caused by the different operating environments.

To illustrate the compatibilities (and incompatibilities) between WPF and SL, he built a Twitter client in both Silverlight and WPF. He started two projects and then basically just copied code from the WPF project and pasted it into the SL project and pressed F5. For the most part this worked great, highlighting the high(ish) level of compatibility between WPF and SL.

First hurdle was the sandbox - the Silverlight client couldn't just call the Twitter service directly due to cross-site call restrictions, so it had to redirect the call through the server. This is not really a compatibility issue, more of an architectural issue caused by the security characteristics of the two environments.

Next hurdle was the lack of Visual State Manager support in WPF. Happily this will be added to WPF in the next release though. In the meantime, it will be available as part of the WPF Toolkit on CodePlex, or you can grab a working WPF VSM from John Gossman's blog. The VSM really simplifies styling, is very nicely supported by Blend, and makes up a bit for the lack of triggers in Silverlight.

Even with a VSM on WPF, control styling behavior may not be exactly the same as in Silverlight. To complete the picture you may need to write a Visual State Behavior for your control. This hooks the control up to the VSM so the states can stay in sync. The Silverlight controls do this automatically but the WPF controls predate the VSM so you need an adapter to hook them up. It looks like the WPF Toolkit contains Visual State Behaviors for some of the controls but not all, so you might have to add a few more. Luckily it looks like they are pretty easy things to write...

There are a couple more compat gotchas of course, but the key thing is that the WPF and Silverlight teams are taking compatibility very seriously, so any kinks will hopefully get ironed as time goes on...

Day 1 is wrapping up now, which means it's nearly time time to meet up with fellow geeks in a hotel bar, drink beer, and capture some more brain power :-)

Prism 2.0 - First Drop

dphill — Sat, 20 Sep 2008 01:31:19 GMT

Woo Hoo! We just released the first drop of Prism 2.0 on our CodePlex site here.

For this first iteration we've focused solely on the "multi-targeting" aspects of Prism (UI composition and modularity support will follow soon though). By multi-targeting we mean the ability to build applications that can provide both a WPF desktop and a Silverlight RIA experience by sharing and re-using code and components between the WPF and Silverlight environments.

[As a side note, we'll probably have to pick another name for this feature soon since it turns out that, to a sizeable number of folks, "multi-targeting" implies targeting different versions of the .NET Framework - see here for example. So to avoid confusion we'll likely have to pick another name for this - maybe multi-headed, multi-experience apps, or something? Vote now on your favorite, or suggest one and win a prize!]

Getting Started

To get started, you'll need to have the following bits installed:

Visual Studio 2008 SP1 (here).
.NET Framework 3.5 SP1 (here)
Silverlight Beta 2 and tools (here)
Silverlight Unit Testing Framework (here)
Visual Studio 2008 SDK (here) - This dependency is temporary and will go away soon (unless you want to recompile or debug the Project Linker).

Finally, download the Prism 2.0 source code zip file and the Project Linker msi from here.

The project linker is a Visual Studio extension that helps to maintain links between projects - more on this below. To install the Project Linker, open up a Command Prompt as an administrator and run the msi like this:

msiexec /i CompositeApplicationGuidanceProjectLinker.msi

The Prism 2.0 zip contains a multi-targeting quick start, as well as the source for the project linker, the acceptance testing library, and a Visual Studio template. Once you've unzipped everything, copy the unit testing framework libraries into the ~\LIB\Silverlight\UnitTestFramework folder and you should be all set. You can also install the Visual Studio templates, though this isn't required.

Running The Quick Start

The multi-targeting quick start contains a simple application that provides a desktop experience (on WPF) and a RIA experience (on Silverlight). The quick start includes projects for the app, associated unit tests, and a small library for displaying simple pie charts. The projects for the desktop version are in the DotNet folder and the projects for the RIA version are in the Silverlight folder.

To run the desktop version, right click on the RealEstateListingViewer.Net project in the DotNet folder, select 'Set As StartUp Project' and press F5.

To run the RIA version, right click on the RealEstateListingViewerHost web project in the Silverlight folder and select 'Set As StartUp Project'. Next, right click on the RealEstateListingViewerTestPage.html page and select 'Set As Start Page', and then press F5.

Not surprisingly, the UI for both versions of the app are pretty much identical.

Accounting for the Differences & Similarities

The app doesn't really do much, it's really just meant to illustrate the code sharing approach to account for the differences and similarities between the WPF and Silverlight environments. This approach uses links to share code source files between WPF and Silverlight projects.

Each project in the quick start solution manages all of the references, resources and code specific to the WPF or Silverlight target environments. Common code that is shared between the two environments is linked from one project into the other project so it gets compiled into each target.

This technique relies on the Visual Studio Add As Link feature that allows you to set up links between files in different projects by selecting the 'Add As Link' menu option to add a link to an existing file in another project.

If you drill into the projects in the quick start solution a little you'll see that the app is split into a number of folders for Images, Models, Services and Views. In the WPF version of the app, the vast majority of the files in these folders are just links to the files in the Silverlight projects. In fact, there are very few WPF or Silverlight specific files - only the root App, RealEstateListingView and Property Service classes are specific. Let's dig into these a little.

The App class accounts for differences in the hosting and initialization model for SL and WPF. Differences here are pretty minor but since this class is generated and typically does not contain much code it is easier to keep the WPF and Silverlight specific classes than to abstract Application into a common class.

The RealEstateListingView class accounts for the fact that in WPF the UI is defined as a Window, while in Silverlight it's defined as a UserControl. The actual differences in the UI are minor and we could have made the WPF view a UserControl too and maybe shared the view across WPF and Silverlight. This example does illustrate an important point though.

For relatively simple views we expect that it will be possible to share views between WPF and Silverlight - and we hope to provide extensive guidance on exactly how to do this. But it's likely that apps will want to take advantage of WPF or Silverlight specific UI features (e.g. 3D, XPS or trigger support in WPF, Visual State Manager in Silverlight, etc). In these cases, you'd want a WPF or Silverlight specific 'skin' for your application (or more likely, for certain key parts of it).

The PropertyService class is responsible for retrieving details of a particular house, including an image of it. The PropertyService class implements the IPropertyService interface, which is how the service is integrated into the common core of the application, but its implementation is actually split over two partial classes. You'll see that both projects contain a common PropertyService.cs file. This defines the GetProperty method of the service. This implementation is shared between the WPF and Silverlight projects and so the PropertyService.cs class is linked.

But you'll also see that the Silverlight project contains a PropertyService.Silverlight.cs file, while the WPF project contains a PropertyService.Wpf.cs. Each of these files defines the specific behavior for the WPF or Silverlight environment and so these files are not shared between projects. These environment specific files define the GetImage method. The implementation of this method is slightly different for WPF and Silverlight - for WPF, the image is loaded directly from disk, for Silverlight, the image is downloaded from the web server.

This is a trivial example but it does illustrate another important point. It's more than likely that an application will sometimes have to employ slightly different strategies when running in WPF and Silverlight environments. Splitting an implementation of a service over two partial classes is one way to cleanly account for these differences. Note that the service interacts with the rest of the core (common) application through a common interface, so this technique is really just a way to factor implementation level details into files that are conditionally compiled for each environment.

This technique is good for accounting for small scale implementation differences between WPF and Silverlight. In other cases you might find that the differences between the environments are coarse grained and don't fit into this pattern well. This is where Prism's support for modules and composition comes in.

Let's take data access an an example. In the WPF case, an offline-capable app will likely be running in full trust and will retrieve most of its data from the local file system and/or a local database and retrieve/sync data over the network only occasionally. In the Silverlight case, the app is running in a sandbox and will most likely access it's data over the network and only use local isolated storage for simple caching.

The differences between these two strategies are probably too big to do cleanly using partial classes, so you'd likely implement them as service agents in different modules with a common interface into the core/common part of the app. Prism will also support this coarser grained composition and allow specific strategies to be plugged in easily and automatically.

The Project Linker

As you can see, the approach we are taking for multi-targeting is based on structuring your application and module code into multiple linked projects. This is a low tech but effective approach that allows common code to be compiled against two target environments.

Manually maintaining the links between files in multiple projects using Visual Studio is possible but it can be time consuming and error prone, so Prism 2.0 provides a 'Project Linker' tool that tries to make it easier to create and maintain the links for you. With the project linker you can specify which projects are related and it will then make sure that common files that you add to one project will be linked into the other project automatically.

With the Project Linker installed as above, you can use it create and maintain links between a source project and a target project so you can auto link shared code that is common to Silverlight and WPF. Let's see this in action...

Right click on the RealEstateListingView.Net solution and click the 'Add Project Link' menu item. This is the target project - the project into which we want to create links. The Project Linker project selector dialog is shown.

We want to link this project to the Silverlight RealEstateViewProject so select that project as the source project and click OK. The project file is now updated to include information about the relationship between the two projects.

The quick start already has all of the relevant links in place so the Project Linker has not really kicked in yet. But, if you now add a new file to the Silverlight project, say in the Services folder, the file will automatically get linked into the equivalent folder of the WPF project. Add a new file called 'MyNewService.cs' and you will see a link show up automatically in the WPF project.

Now, say you wanted to add a file to your project but didn't want it linked into your WPF project. The Project Linker uses filters to decide when to auto create links. By default, if you add a file with a .Silverlight.cs or a .WPF.cs suffix, as in the quick start, they will be ignored by the project linker and won't get auto linked.

The functionality for the Project Linker is fairly basic at the moment. We want to validate that the code sharing through links approach works before we invest too much effort in it. To make it more usable and useful we'd like to add the ability for the developer to see what projects are linked and allow them to change and remove links.

We'd also like to add the ability for the developer to define custom filter rules so that they can decide what convention is used to create or prevent auto link files. The default rule is based on the .Silverlight.cs or .WPF.cs suffix, but you may want a different naming convention, or use a certain folder structure to contain specific or shared files regardless of the file names.

If you have any feedback on Prism 2.0, please let us know. We're eager to find out whether the code sharing approach is a workable solution (in the unfortunate absence of binary compatibility) and what folks would like to see in the Project Linker. We're working on the next iteration now, which focuses on module loading, so expect another drop in a couple of weeks.

Application Architecture Guide 2

dphill — Fri, 12 Sep 2008 20:50:59 GMT

Those of you who remember ye olde days of yore when .NET 1.0 and 1.1 were the latest and greatest thing may also remember the Patterns and Practices Application Architecture Guide. It was published waaay back in December 2002, and it has consistently been one of our most popular guides overs the years.

But time and technology has marched on relentless and so the AAG is getting a bit long in the tooth now. The architectural principles and concepts that it describes are still highly relevant of course - which is one reason for its longevity and continued popularity - but the guidance on how to best leverage the .NET platform and its constituent technologies to build applications and solutions desperately needs an update.

It's been a long time coming but I am happy to report that we are now working on Application Architecture Guide V2.0 (I guess that should be Second Edition). J.D. Meier is driving this project and has just announced the effort on his blog, along with a pointer to the project's CodePlex site here.

A lot has changed since 2002, both in terms of the technologies and the capabilities of the .NET platform and in the types of applications that folks are building these days. Application Architecture is obviously a rather large field and we could produce volumes and volumes of guidance on all of its various aspects, but this would not be practical. So to keep the guide manageable and useful we're hoping to keep the guide around the 200 page mark. The guide will be somewhat high level, as was the first edition, but it will serve as a frame of reference and a jumping off point for more detailed guidance on specific technologies, patterns and techniques.

We've had strong feedback that the guide should provide guidance on choosing the right architecture for an application, and on choosing the right technologies to implement that architecture. For the former, the guide will describe a number of Application Archetypes, canonical architectures for common application types. For the latter, the guide will describe the capabilities and salient features of the various technologies and provide guidance on how to choose between them. The guide will also cover Architectural Qualities - like performance, scalability, manageability, etc - that have to be factored in when building applications.

J.D. describes some of the high level areas that we're looking to cover in the guide in his blog post. What would you like the guide to cover? Are there specific topics or areas that are important that are missing or under-represented? Head on over to the AppArch CodePlex site and let us know!

Prism on DNR and MSDN

dphill — Fri, 05 Sep 2008 20:32:55 GMT

Patterns & practices alumni Glenn Block has been busy writing and talking about Prism 1.0 recently:

First up, he and Brian Noyes recorded an interview with those nice Dot Net Rock chaps at TechEd which just got posted here. Looking forward to listening to that once it shows up on my Zune...

And second, Glenn's written a very nice article for the September edition of MSDN magazine, which is now available online right here.