.NET & Funky Fresh

MVVM Study Part 4: Naked WPF

Rob Eisenberg — Fri, 13 Nov 2009 15:47:00 GMT

I’ve blogged previously about the MVVM pattern, but so far I have managed to escape without showing any code ;) Before diving in deeper, I would like to stop and show what it takes to do a very simple implementation of this pattern on top of naked WPF (that’s plain WPF without any cool frameworks).

After all my praise of MVVM and how well matched it is with WPF/Silverlight, you might be surprised to hear me suggest that it’s not possible to implement without building a little infrastructure first. It’s true. But, we really only need to create one class:

public class DelegateCommand : ICommand
{
    private readonly Action _execute;
    private readonly Func<bool> _canExecute;

    public DelegateCommand(Action execute)
        : this(execute, () => true)
    {
        _execute = execute;
    }

    public DelegateCommand(Action execute, Func<bool> canExecute)
    {
        _execute = execute;
        _canExecute = canExecute;
    }

    public void Execute(object parameter)
    {
        _execute();
    }

    public bool CanExecute(object parameter)
    {
        return _canExecute();
    }

    public event EventHandler CanExecuteChanged
    {
        add { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested -= value; }
    }
}

The DelegateCommand is a common solution which allows us to adapt WPF controls, which accept an implementation of ICommand, to our ViewModel, which has simple properties and methods. (If you want to make this work in Silverlight 3.0, you are going to have to build a little more infrastructure.) Here’s an example of how you would use it as part of a fictitious employee creation screen:

public class CreateEmployeeViewModel : INotifyPropertyChanged
{
    private string _firstName;
    private string _lastName;

    public CreateEmployeeViewModel()
    {
        SaveCommand = new DelegateCommand(Save, () => CanSave);
    }

    public string FirstName
    {
        get { return _firstName; }
        set
        {
            _firstName = value; 
            NotifyOfPropertyChange("FirstName");
        }
    }

    public string LastName
    {
        get { return _lastName; }
        set
        {
            _lastName = value; 
            NotifyOfPropertyChange("LastName");
        }
    }

    public ICommand SaveCommand { get; private set;}

    public bool CanSave
    {
        get { return !string.IsNullOrEmpty(FirstName) && !string.IsNullOrEmpty(LastName); }
    }

    public void Save()
    {
        MessageBox.Show("Saved.");
    }

    public event PropertyChangedEventHandler PropertyChanged = delegate { };

    public void NotifyOfPropertyChange(string propertyName)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

The SaveCommand property allows us to use normal data binding in our view:

<Window x:Class="MVVMStudy.PartFour.CreateEmployeeView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        SizeToContent="Height"
        Width="400">
    <Grid Margin="4">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="Auto" />
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto" />
            <RowDefinition Height="Auto" />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>
        
        <Label>First Name:</Label>
        <TextBox Text="{Binding FirstName}" 
                 Grid.Column="1"/>
        
        <Label Grid.Row="1">Last Name:</Label>
        <TextBox Text="{Binding LastName}" 
                 Grid.Row="1"
                 Grid.Column="1"/>
        
        <Button Content="Save"
                Command="{Binding SaveCommand}"
                HorizontalAlignment="Right" 
                Margin="0 4 0 0"
                Grid.Row="2"
                Grid.ColumnSpan="2"/>
    </Grid>
</Window>

And in our code behind:

public partial class CreateEmployeeView : Window
{
    public CreateEmployeeView()
    {
        InitializeComponent();
        DataContext = new CreateEmployeeViewModel();
    }
}

Now you know a little more concretely what a WPF/SL dev means when they reference MVVM (Actually, all I have shown here is VVM. Presumably you have a real employee model that you are saving in the save method or a web service you are calling. That’s the missing M and isn’t really the focus of this series.) But even then, this doesn’t get you very far. If you are like me, you probably have a lot of questions still. You might we wondering:

What happens if I have a complex View Model with lots of properties and actions?
How do I organize my View Models and Views?
How do I pass contextual data to a View Model?
Who creates View Models and associates them with the proper View?
Do I really have to host instances of DelegateCommand on my View Model?
How would I allow the user to work with multiple employees at the same time?
How do I prevent unsaved changes from being accidentally lost?
How do I handle dialogs?
How do I manage contextual menus and toolbars?
How long is this series going to go on?

We’ll take a look at answers to some of these questions in future posts.

A Follow-up to my Azure Panic Attack

Rob Eisenberg — Sun, 08 Nov 2009 21:25:00 GMT

In this post, I panicked a bit about an email I received from The Azure Team ;) In short, the email said that my storage account was going to be deleted on November 3rd if I didn’t migrate it to the new servers. I received the email around 6pm on November 2nd. Yikes! I feared that we might lose all of Silver Arcade’s assets. After a bit of research, I discovered that I should have received a similar email warning me about this change several months ago. Something went wrong somewhere, somehow. In any case, I managed to get all of our data backed up using Cloud Storage Studio which Bill Reiss had recommended to me. While I was doing this, I was frantically trying to get into contact with someone from the Azure team. I emailed Steve Marx. He responded quickly and had a plan of action. We had a short email exchange and within a couple hours I was in contact with the right people. The Azure Team to the rescue! Once the team was made aware of my situation, they offered to migrate my data for me. Awesome! While I started out the evening in a bit of a panic, the Azure team restored my confidence. They treated me well and met my needs with excellence. Thanks for being committed to your customers!

Microsoft, what is the meaning of this?

Rob Eisenberg — Tue, 03 Nov 2009 00:01:21 GMT

I just received this email on November 2nd at 6pm. I hadn’t heard a word of this prior. Thanks for the warning…

Windows Azure CTP participant,

You are receiving this mail because you have an application or storage account in Windows Azure in the “USA - Northwest” region. Windows Azure production applications and storage will no longer be supported in the ‘USA-Northwest’ region. We will be deleting all Windows Azure applications and storage accounts in the “USA - Northwest” region on November 3rd.

To move your application/storage, first delete the project using the “Delete Service” button. Then recreate it, choosing the “USA - Southwest” region. (It may take a few minutes for your previous application and storage account names to become available again.)

Note that deleting your storage account will destroy all of the data stored in that account. Copy any data you wish to preserve first.

If you would like help migrating your project or have any other concerns, please reply to this mail.

- The Windows Azure Team

NHProf and Caliburn Testability

Rob Eisenberg — Fri, 30 Oct 2009 19:07:00 GMT

I’ve heard some developers asking about UI testing lately. Specifically, there have been some questions about what we did with NHProf. So, I thought I would write a little bit about that here.

There are a variety of different types of tests you can do. In my experience some have a better ROI than others. For example, we don’t do any UI testing with automation APIs. Those are pretty painful, brittle tests to write and we haven’t worked in scenarios where they would really help us. The two main types of UI testing we tend to do are Unit Tests of the View Model and Binding Validation Tests against the Views.

View Model Tests

There are many advantages in taking a View Model approach to building your UI. When we build VMs we try and push as much of the UI state into our models as possible. By doing this we “virtualize” our entire UI, allowing us to simulate a large percentage of the UI behavior without ever opening a Window or showing anything on screen. This is great for testability. It means, we can use simple state based unit tests to verify the behavior of our UI. Here’s a simple example from NHProf:

public class StatementFilterTestFixture
{
    private readonly FilterServiceModel service;
    private readonly IList<IStatementSnapshot> statements;

    public StatementFilterTestFixture()
    {
        statements = new List<IStatementSnapshot>
                         {
                             create_a_statement(100, "hello"),
                             create_a_statement(200, "select * from something"),
                             create_a_statement(300, "select field1 from something"),
                             create_a_statement(400, "select monkey,ninja,pirate,robot from floating_island"),
                             create_a_statement(500, ""),
                         };

        service = new FilterServiceModel();
    }

    [Fact]
    public void Can_filter_by_both_duration_for_values_less_than_300_and_contains_text()
    {
        var filters = new ObservableCollection<IFilter>
                          {
                              new FilterByDuration
                              {
                                  Operator = ExpressionType.LessThan, 
                                Value = "300"
                              },
                              new FilterBySqlContains {Text = "something"}
                          };

        service.Filters = filters;

        Assert.Equal(1, statements.Where(x => service.FilterStatement(x)).Count());
    }
}

Binding Validation Tests

While the WPF/SL data binding mechanism opens the door to building rich View Models, it also introduces a new problem: potential binding expression errors. Because we didn’t want to give up the productivity benefits of databinding and View Models, we chose to take some time to build a binding validation framework. We then write simple tests to insure that there are no typos or silly mistakes in our binding expressions. Here’s an example test from NHProf:

public class StatisticsDetailsTestFixture : ViewTestFixtureBase
{
    private readonly ValidationResult<StatisticsModel> bindings;

    public StatisticsDetailsTestFixture()
    {
        bindings = Validator.For<StatisticDetailsView, StatisticsModel>()
            .Validate();
    }

    [Fact]
    public void BindingsDoNotHaveErrors()
    {
        Assert.False(bindings.HasErrors, bindings.ErrorSummary);
    }

    [Fact]
    public void NameIsBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.DisplayName));
    }

    [Fact]
    public void StatisticsAreBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.SortedStatistics));
    }
}

You can actually take this one step farther as José Romaniello has in testing his Chinook Media Manager. Take a look at this sweet piece of code.

Caliburn v1 RTW for WPF, Silverlight 2.0 and 3.0!

Rob Eisenberg — Mon, 26 Oct 2009 17:06:00 GMT

Hooray!!! I finally released Caliburn v1 to RTW and got the official site launched! This has been a long time coming and I could not have done it without the generous help and support of the .NET community, family and friends. Many individuals contributed by finding bugs, submitting patches, recommending features or improvements and providing general support and encouragement. I would like to call out a few special individuals (in no particular order) who contributed significantly:

Michael Davis – For submitting numerous bug fixes and patches.
Ryan Rauh – For creating the fabulous Prism integration module, which I believe makes Prism easier to use with Caliburn than without!
Marco Amendola – For implementing several new features, fixing tons of bugs, submitting patches, writing demos and being an awesome help answering questions on the forums!
Christopher Bennage – For fixing bugs, inventing and inspiring cool features, participating in the forums, believing in my vision and being willing to put this framework to the test on every WPF/SL application our company has built for the last several years.
Anna Eisenberg – It goes without saying that my wife has been very gracious to me. She has supported and believed in me and my work without faltering. I love you!

I would also like to thank the codeplex users MichaelDBang, Bezieur, p_matyjasek and davidpadbury for their patches and participation in the forums. And, as always, if I left someone out, I sincerely apologize. (I’m going to do a better job of tracking this stuff for v2…)

In addition to the release build and the official site, we’ve added a gallery of applications and related projects to our new documentation. In the coming months I am going to be extending this documentation with additional articles in my MVVM series as well as some cool tutorials.

For those of you who have never heard of Caliburn, it is a UI framework designed to aid in the development of WPF and Silverlight applications. Caliburn implements a variety of UI patterns for solving real-world problems. Patterns that are enabled by the framework include MVC, MVP, Presentation Model (MVVM), Commands and Application Controller. Here’s a bullet point list of what Caliburn gives you that you don’t get from WPF/SL out of the box:

Extends databinding to methods, making MVVM architectures simple and intuitive.
Adds pre/post execution filters and rescues to MVVM actions.
Simplifies asynchronous programming through a powerful implementation of Coroutines.
Provides base classes supporting common UI roles such as Screen Activator, Screen Conductor, Screen Collection and Application Controller.
Encourages a convention over configuration approach to architecting solutions.
Supports TDD by providing a powerful databinding validation framework for WPF.
Enables use of the same API for WPF and Silverlight architectures

Here’s a more detailed explanation of its key features:

Actions

Actions extend the databinding capabilities of WPF/SL by enabling a UI to bind not only to data but to methods as well. Caliburn provides a consistent API for wiring events, gestures, and attached events to methods on a presentation-related class. This type of method binding removes much of the glue code involved in building an MVP or Presentation Model (MVVM) architecture. In addition to basic execution of methods, Caliburn's action mechanism can pass data from the UI into the methods as parameters and bind return values back to the UI. A filter mechanism (similar to ASP.NET MVC) exists for decorating methods. Filters can affect the availability of a given action through the UI, which can be represented by automatically disabling, hiding or collapsing controls. Caliburn can also automatically execute methods asynchronously, and execute callbacks. It does all the thread marshalling for you. If that's not enough power, you can take advantage of Caliburn's Coroutine implementation through actions as well.

Commands

Caliburn's command implementation is an alternative to WPF's and supplies very useful functionality that is altogether missing from Silverlight. As you might expect, it is an implementation of the Command Pattern.. Commands are built on top of Actions and thus share many of the same features, including multiple input parameters, filters and automatic asynchronous execution. Additionally, commands can be created in hierarchies, such that a parent command can execute multiple child commands. The parent command's availability can also be affected by its children in various ways. There are two types of composite commands available out of the box, but the mechanism is extensible.

Application Model

Caliburn supports UI architectures based on MVP and MVVM through its various implementations of the IPresenter interface. Often times, these types of architectures involve tricky UI lifecycle issues such as handling activation, deactivation and shutdown semantics for various UI components. The basic logic for handling these scenarios is found in Caliburn’s Presenter, PresenterManager, MultiPresenter, MultiPresenterManager and Navigator classes. By composing these classes you can create a hierarchical model representing the entire runtime state of your application. In Silverlight, you can even use the browser as an Application Controller with Caliburn’s support for deep linking. By using these classes as a starting point, you can very quickly get up in running with an MVP or MVVM architecture.

Conventions

Convention over configuration is a way to leverage a great deal of a framework's power without having to go through tons of tedious configuration or setup code. Caliburn has basic conventions around view discovery, binding of actions and building-up of hierarchical View Models. These are all implemented through well-known services which are easily replaceable or extendable with your own conventions.

Testability

One of the goals of Caliburn is to make it easier to build applications right. To this effect, Caliburn has features geared around unit testing. There is currently rich support for testing databindings in WPF and a simple fluent interface for verifying change notification on model objects. Unit tests for view bindings give the developer the confidence they need to refactor their models, knowing that they will be aware of broken bindings before they run the application. Not only will they be aware that the bindings are broken, but Caliburn’s binding validator will tell you exactly where the problem is in the UI hierarchy and what the specific error was.

Utilities

Various utility classes and extension methods are provided as part of Caliburn. The most popular of which is the Execute static class, which enables a developer to easily execute code on a background thread or on the UI thread.

Caliburn has come a long was since I first started working on it about three years ago and we are not finished yet. I’ve got a host of ideas for v2 and now is a great time to get started. Download the framework. Start using it to build UI’s, give me feedback and help us make it even better in v2!

With Much Gratitude (and hoping this makes your work a little easier),

Rob Eisenberg

Caliburn RC3

Rob Eisenberg — Thu, 10 Sep 2009 19:42:00 GMT

Today I’ve made the RC3 of Caliburn v1 available. I’m going to let it sit for a couple of weeks, then I will RTW. Please take time to update your code to this new version and post any bugs to the codeplex site. Any bugs not found in the next couple of weeks will have to be fixed in v2. Below is a list of changes/fixes between RC2 and RC3. You can also take a look at the recently extended documentation online.

Updated the StructureMap.dll to version 2.5.3.
Made a slight alteration to CoreConfiguration that makes it more friendly when run in a unit test.
Added an AutofacAdapter for .NET 3.5, Silverlight 2.0 and Silverlight 3.0.
Fixed bugs in the DefaultWindowManager.
Added IPresenterNode which allows presenters to be hooked up with a reference to their parent. All implementors of IPresenterHost now wire themselves when opening children and unwire themselves during a shutdown.
Created the IBinder interface. This replaces the functionality that was in the extension method AttachTo. This interface is meant to provide a pluggable way to change the behavior of Model/View wire-up.
Updated DefaultBinder to allow for convention-based action wire-up.
Fixed a bug in auto-registration with CommandAttribute.
Fixed several bugs with CaliburnApplication
Fixed a bug where certain module scenarios would cause the PresentationFrameworkModule to be configured twice.
Fixed some inconsistencies in the DefaultWindowManager and CaliburnApplication.silverlight.cs.
Removed a pesky attribute in the WPF ContactManager's .config file that was causing bugs for some people.
Removed Message.Attach2nd, Message.Attach3rd and Message.Attach4th. You can now attach an arbitrary number of messages with Message.Attach by separating each message with a semicolon. This caused a breaking change to the IParser implementation, but it is unlikely that will affect many people.
Fixed some bugs in Parameter.silverlight.cs related to event defaults for elements that are bound.
Improved the BackgroundProcessing sample.
Fixed some bugs in parsing of parameters for messages. There were certain scenarios where the parser could not differentiate between string literals and references to control. To pass literals as a message parameter (short syntax only), you must surround it with single quotes.
Added AttachedEventTriggerParser. We can all now use attached event triggers in the short syntax. Usage is as follows: cal:Message.Attach="[AttachedEvent ButtonBase.Click] = [Action MyAction]" The caveat is that we cannot map namespaces from xaml into the parser. To work around this problem, we search through all AppDomain assemblies by default. If you would like to optimize this, simply inherit from AttachedEventTriggerParser and override GetSearchableAssemblies. Then register your ITriggerParser with IParser under the name "AttachedEvent"
Enabled the DefaultViewStrategy to handle custom contexts without the need of a ViewStrategyAttribute. If a context is the DefaultViewStrategy will treat the view name as a folder name by adding an "s" and search that folder for views with the context as their name.
Fixed various bugs in DefaultViewStrategy.
Fixed various bugs in AsynchronousAction and in the BackgroundProcessing sample.
Updated MEF to Preview 7.
Changed IMessageBinder.BindOutcome to IMessageBinder.CreateResult.
Enabled the DefaultBinder to look for properties named with the pattern Can + Action and wire up the IsEnabled property automatically.
Fixed the signatures of extension methods for IWindowManager.
Fixed a bug in binding validation that occurs when properties are overridden on a bound type.
Provided a way for a presenter to pass a dialog result to the view on close.
Made some improvements to exception messages in the case of parameter count mismatch during invocation.
Updated Caliburn's build to work with Silverlight 3.0.40818.0 service release.
Extended the IDispatcher to allow async UI invocation.

Dispelling a Common WPF/SL Myth

Rob Eisenberg — Tue, 08 Sep 2009 16:13:00 GMT

Everywhere I look I find WPF/Silverlight developers who believe a very popular myth: You cannot update a ViewModel or an ObservableCollection from a non-UI thread. Like most myths, there is an element of truth here. But not understanding that truth can lead you to some very elaborate solutions. Here’s the truth: You cannot fire the change notification from a non-UI thread. So with that in mind, it becomes very easy to abstract thread synchronization away. Here’s how we do it in Caliburn:

public abstract class PropertyChangedBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged = delegate { };

    public virtual void NotifyOfPropertyChange(string propertyName)
    {
        Execute.OnUIThread(() => RaisePropertyChangedEventImmediately(propertyName));
    }

    public virtual void RaisePropertyChangedEventImmediately(string propertyName)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

public class BindableCollection<T> : ObservableCollection<T>, IObservableCollection<T>
{
    public BindableCollection() {}

    protected override void OnPropertyChanged(PropertyChangedEventArgs e)
    {
        Execute.OnUIThread(() => RaisePropertyChangedEventImmediately(e));
    }

    protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
    {
        Execute.OnUIThread(() => RaiseCollectionChangedEventImmediately(e));
    }

    public void RaiseCollectionChangedEventImmediately(NotifyCollectionChangedEventArgs e)
    {
        base.OnCollectionChanged(e);
    }

    public void RaisePropertyChangedEventImmediately(PropertyChangedEventArgs e)
    {
        base.OnPropertyChanged(e);
    }
}

The Execute.OnUIThread is a helper that Caliburn provides to abstract away the underlying IDispatcher. When Caliburn’s dispatcher is asked to execute something on the UI thread it first checks the thread it is on. If it is already on the UI thread, it simply invokes the delegate normally. Otherwise it marshals the call to the UI thread. This approach also makes testing easy, because you will never find any threading code in a ViewModel. Everything ultimately goes through an IDispatcher which Caliburn provides a fake implementation of for testing purposes.

Tallahassee Code Camp is Upon Us!

Rob Eisenberg — Fri, 04 Sep 2009 19:18:00 GMT

Tomorrow at the FSU College of Communication and Information we will hold Tallahassee’s 5th Annual Code Camp! We have a great list of speakers and some awesome sessions planned. Please check out our official site.

MVVM Study Part 3 – Why?

Rob Eisenberg — Tue, 01 Sep 2009 20:39:00 GMT

There are several major architectural approaches used in building user interfaces. MVC, MVP and MVVM seam to be the most popular of the bunch. From among them, MVVM has risen to the top of the stack for WPF and Silverlight developers. Even ignoring the question “Why use separated presentation at all?”* and asking “Why MVVM?” yields an answer with many facets. In this post I’m mostly interested in in how MVVM exhibits Conceptual Integrity with WPF/SL. I believe that it is for this reason that most developers are using MVVM over another pattern. For a very good discussion of some other aspects, have a read of Glenn’s recent post.

Here’s how the book Beautiful Architecture describes Conceptual Integrity:

“Conceptual integrity comes from consistency in things like decomposition criteria, application of design patterns, and data formats. This allows a developer to apply experience gained working in one part of the system to developing and maintaining other parts of the system. The same rules apply throughout the system.”

Even if you haven’t pondered the concept of Conceptual Integrity explicitly, you have more than likely felt when it was not present in a given architecture. I think this term describes well the sentiment held by developers switching from WebForms to ASP.NET MVC (or Rails for that matter). WebForms does not exhibit Conceptual Integrity in the context of the Web, while MVC does.

Below are three WPF/SL concepts with which I think the MVVM pattern resonates well. That is to say, the MVVM pattern came to the forefront of UI design patterns for WPF/SL because it is consistent with the following core concepts of the platform:

Databinding

WPF and Silverlight have richer databinding support than has previously been available on the Windows platform (perhaps any platform). If you talk to an experienced WPF developer, I would be surprised if he/she didn’t list this as one of the most, if not the most important aspect of the framework. It is what enables a developer to create a fairly pure model (the ViewModel) and then stick the View on top of it. Databinding is the “adhesive” that allows us to get rid of the manual push/pull synchronization code that is required in an MVP design. Indeed, the original PresentationModel pattern, arose in correlation with earlier databinding mechanisms.** So, it’s not surprising that WPF’s super-charged databinding would bring this pattern to the forefront and give it a new name: ViewModel. In short, databinding provides a consistent mechanism through which a developer can describe how a View and ViewModel will interact.

Templates

If you look at the WPF/SL control architecture, you’ll notice something quite interesting: A Control’s behavior and its View are separated. The platform splits controls into two parts, the Control class (ViewModel) and the ControlTemplate (View). Yes, one reason why MVVM makes sense is because the platform itself is architected in that way. Recalling the previous point: How do you describe the interaction between the Control Class and the ControlTemplate? TemplateBinding. Of coarse, you could venture to build your own MVVM architecture by creating your VMs as descendants of Control and then defining Views as ControlTemplates (please don’t do this). But, there is a better way. DataTemplates extend the same concept by allowing Views over any type of object. And of coarse, Databinding is used to glue the object to the template. So, you can imagine how Gossman’s original description of MVVM was very intuitive for him even if he hadn’t read Fowler’s description of PresentationModel. It was a logical extension of the underlying platform.

Composition

Fowler has this to say:

“In the case of composition a Presentation Model may contain one or many child Presentation Model instances…”

And Gossman says*** that the MVVM pattern has a

“hierarchical nature … as we practice it”

WPF is a composition-based framework at its core. Consider the RichTextBox control. It’s behavior is in the control class. Now, look at its ControlTemplate. It typically contains a ScrollViewer. That’s a completely different control with its own behavior and view. Here’s where it gets really interesting. When you create a RichTextBox, at runtime, WPF is composing the behavior of multiple controls and in parallel composing the views of those controls (because the ScrollViewer is composed of ScrollBars…which have their own behavior/view). You can, of coarse, accomplish the same thing with DataTemplates and ViewModels. In many ways, I think this is the real ultimate power of WPF/SL. I’ve found this to be an extremely important concept. When tackling a complex screen, decompose it into a series of smaller models. WPF’s compositional nature encourages this, as it can easily put the pieces together for you.

Final Thoughts

I’ve listed a very small number of concepts that I believe are central to development with WPF/SL. It is out of these same concepts that MVVM naturally emerges. I’m sure many WPF devs started building things this way without reading either Gossman or Fowler. It makes sense for the platform. It exhibits Conceptual Integrity.

* I’m ignoring it because it has been answered very thoroughly many times before and I’m assuming you have already decided this is a good idea.

** Note that Fowler hopes .NET will bring improved databinding to the scene.

*** Actually, Gossman’s second explanation of MVVM is the better of the two. I’m afraid far less people have read this than the original.

Herding Code 57 – Presentation Pattern Goodness

Rob Eisenberg — Wed, 19 Aug 2009 23:26:00 GMT

If you are interested in presentation patterns, Jeremy Miller, Ward Bell, Glenn Block and myself discuss the subject on the latest Herding Code (57).

MVVM Study Part 2 – “View of the Model” or “Model of the View” ?

Rob Eisenberg — Sun, 02 Aug 2009 21:38:00 GMT

As a follow-up to my last post on MVVM, I want to further investigate the ViewModel as a concept. In commenting on my blog, one reader describes a ViewModel as “a UI oriented abstraction of the model.” In that sense, he is saying that a ViewModel (VM) is simply a contextual “View of the Model” and that it is confusing to think of it in any other way. However, when we construct a VM, we do so with the explicit intent of creating a public surface area that is easily bindable and supportive of the UI itself. Therefore, the public properties and methods/commands exposed by the VM tend to form a “Model of the View.” How do we justify these two views? Are they really at odds with one another or are they merely two sides of the same coin?

Confusing Abstractions

One reason VM is confusing stems from its frequent use as an Adapter, where it enables the incompatible interfaces of the UI and domain model to talk to one another. However, using a VM for this purpose is mixing concerns. A better solution would be to have an explicit Facade/Adapter/Bridge handle communication between layers, freeing the VM to vary independently from the domain model. When I’ve failed to make this distinction in the past, I’ve been burned…bad. Nevertheless, even if your VMs do operate like an extremely intricate adapter, it’s often quite unhelpful to think of the problem in this way. Doing so can lead you to miss the realization that a VM has its own set of concerns, which primarily center around supporting the UI, not abstracting the domain. That is to say, we don’t build a VM for the purpose of abstracting the domain model, we build it to power the UI.

How I Think

When I’m constructing a system, I prefer to think of the VM as a state machine with the View being a visualization of the current state. The user interacts with the View, causing “messages” (actions/commands/bindings) to be sent to the VM. The VM receives and delegates or interprets these messages, which may or may not result in state changes and may or may not result in domain model interaction. (I’ll discuss what these state machines look like more in future posts.) The important thing to remember is that the VM is in control; the view makes “suggestions,” but the VM decides what happens when.

The Flip Side

So, for me, the most helpful way of thinking of a VM is as a “Model of the View.” But, is there value to the notion of “View of a Model?” I had to go back and look at concrete code samples from past projects, consider what we did, why and what did or did not work before I could settle on an answer I feel confident about. I saw code that I wrote two years ago in which I mixed adapter qualities with the view model rather than carefully thinking about modeling the view’s behavior. It was hideous. I’m not sure what I was thinking, but I wasn’t creating a “Model of the View.” Then I looked at NHProf’s code which has an explicit bridge (IBackendBridge) and a structural VM, whose implementation was easy to adapt and extend over the coarse of major architectural change. It’s code has remained relatively simple and concise while delivering a rich feature set. Here’s what I have determined. If your view model happens to look like an abstraction of the domain or “View of the Model,” that shouldn’t surprise you. It is a natural consequence of that fact that the entire presentation layer of your application is at a higher level of abstraction than the domain model. From time to time you should think of your VM in this light. It’s likely that doing so will reveal some implicit concepts in your domain which need to be made explicit. This happens because the VM closely models exactly what the users are doing. So, there is value in thinking in this way, but this value is completely different than what is gained from trying to model a view.

Summary

When building your VM, try to think of it as a “Model of the View,” but when building your domain model revisit your VM, trying to see it as a “View of the Model” and ask yourself if the VMs implementation has any implications for your domain. Naturally, this really only works when utilizing an iterative design methodology…

Caliburn v1 Release Candidate 2 is Available!

Rob Eisenberg — Sat, 25 Jul 2009 20:27:00 GMT

I’ve put a ton of work into this release and I think we are finally almost ready for RTW! You can get the new RC2 bits here. Please download them, try them and help me squash any final bugs that may remain. Below is a list of things that have changed since RC1, its quite significant:

Added the official xmlns for caliburn: http://www.caliburnproject.org
Added a Completed event to IResult (renamed from IExecutableResult)
Renamed CompositeResult to SequentialResult
Added a Starting event to IBackgroundTask.
The filter interfaces have been renamed IPreExecuteFilter -> IPreProcessor, IPostExecuteFilter -> IPostProcessor, IRescueFilter -> IRescue, IInstanceAwareFilter -> IHandlerAware. Also, IMethodBinder was renamed to IMessageBinder and IMessageSupportingMethodBinding was renamed to IRoutedMessageWithOutcome (which caused a change in the IResult interface). The property ReturnPath on ActionMessage was renamed to OutcomePath.
Enabled Unity, Castle, Ninject and MEF Adapters for Silverlight.
Improvements to DefaultViewStrategy
Added parameter and results of message to be bound to Resources.
Enabled parameter special files to be "dotted" on. ie: $eventArgs.My.Property
Additional attached properties are necessary: Attach, Attach2nd, Attach3rd and Attach4th
IPresenterHost's Presenters is now an instance of IObservableCollection<IPresenter>
Introduced IAssemblySource as a way for any component to be made aware of inspectable assemblies.
Reworked ComponentInfo
Added the IWindowManager service for WPF. This enables a model-centric mechanism for showing dialogs and non-modal windows.
Added the IViewAware interface which can be implemented by a model/presenter if it wishes to be aware of its view.
Updated the build to compile for .NET 3.5, Silverlight 2.0 and Silverlight 3.0
Updated all samples so that they has both SL2 and SL3 projects.
Many more small features and API improvements...
Fixed tons of bugs...

Asynchronous Execution, Animation and more in MVVM with Caliburn

Rob Eisenberg — Fri, 10 Jul 2009 04:21:24 GMT

On the Silverlight Insiders mailing list there’s been a discussion about the difficulties of handling animations when trying to use an MVVM architecture. I’m not going to go into the details here, as I am going to cover this more fully in a future blog post, but still, I could not resist showing off the elegant way that Caliburn solves this problem. Here is some XAML:

<TextBox x:Name="username" />
<PasswordBox x:Name="password" />

<Button Content="Login"
        pf:Message.Attach="Login(username.Text, password)" />

And here is the code from the ViewModel that Caliburn execute when the user clicks the button:

public IEnumerable<IResult> Login(string username, string password)
{
    _credential.Username = username;
    _credential.Password = password;

    var result = new Result();
    var request = new GetUserSettings(username);

    yield return new ProcessQuery(request, result, "Logging In...");

    if (result.HasErrors)
    {
        yield return new ShowMessageBox("The username or password provided is incorrect.", "Access Denied");
        yield break;
    }

    var response = result.GetResponse(request);

    if(response.Permissions == null || response.Permissions.Count < 1)
    {
        yield return new ShowMessageBox("You do not have permission to access the dashboard.", "Access Denied");
        yield break;
    }

    _context.Permissions = response.Permissions;

    yield return new OpenWith<IShell, IDashboard>();
}

Please note that the 1st, 2nd and 3rd yield statements above are all *asynchronous*, but the code within this action is executed in sequential order. The 1st yield also triggers an animation...I can also do things like this:

yield return new BeginAnimation("MyCoolAnimation");
yield return new BeginAnimation("This animation is next");
yield return new BeginAnimation("This animation plays last");

This gives the View Model a declarative way to handle animations without a need to reference the view. Also, it should be noted that the above action relies on several UI services, but I can unit test this action without needing to mock anything. The declarative nature of the action allows me to iterate over the results and simply use normal Asserts on the values. Async programming becomes synchronous and playing Animations is peachy ;)

More on this later, but I just had to show some code because I’m not sure many people know you can do this with Caliburn. On my current Silverlight project, we are making extensive use of this. It makes calling web services a breeze.

MVVM – Philosophy and Case Studies - Introduction

Rob Eisenberg — Wed, 08 Jul 2009 02:49:00 GMT

There’s been a lot of talk lately about MVVM (Model-View-ViewModel) in the WPF and Silverlight space. Recently, Ward Bell had an interesting post on the subject where he digs into some of the patterns he is using to support his MVVM triads. The WPF/Silverlight community is constantly droning MVVM, but almost no one goes beyond stating their use of the pattern or giving an overly general description of it. That’s why I enjoyed Ward’s post. He’s trying to get into the nitty-gritty of his UI architecture rather than just chanting “I'm using MVVM" and leaving it at that.

I’m pleased that the WPF/SL community is taking UI architecture seriously, but I think we have a long way to go. We need to dig deeper into the “how” of the MVVM and realize that a solid implementation is more that just creating a model and binding it to a view, with a dash of the Command pattern thrown in for good measure. In fact, saying you are using MVVM for WPF/Silverlight is sort of like saying you are using MVC for web development. It more or less states the general design approach you are taking to the UI architecture, but doesn’t say much about how the pattern is implemented or how individual features are represented within the context of that design. If you’ve been following the blogs on ASP.NET MVC, you’ve probably discovered that there is a lot more to it than just having Models, Views and Controllers. It is easy to use the MVC pattern very poorly and the same goes for MVVM.

Speaking of context…

When I first read the GoF book, I was baffled by its insistence that patterns were not tied to implementation. Sure, I understood that the Iterator pattern would be implemented differently in C++ than in C#, but I didn’t understand that other context-specific factors had a massive affect on the details of its implementation. This “phenomena” manifests itself in greater degrees with respect to how high-level the pattern is. A high-level pattern like MVC is a fine example of this. Consider how the implementations would differ between a WinForms and an ASP.NET implementation of this pattern. They would not resemble each other much at all. The WinForms version would likely look a lot like an Observer or Mediator while the ASP.NET version would be very similar to a Strategy. In fact the WinForms version would look so different, you might not even call it MVC anymore, though you started out with an MVC mindset. You could force the WinForms and ASP.NET implementations to look alike, but you would be creating a leaky abstraction by forcing an artificial context for your design to live in.

In the next couple of posts I am hoping to examine MVVM within the context of WPF/SL. What does the base form of it look like? What do more complex forms look like? Why is this pattern a good fit for WPF/SL? How does this pattern relate to MVP and MVC?

MVVM – A Simplistic View

If we take MVVM as a high level pattern, like MVC, then it becomes our general approach to architecting user interfaces. It means that we will have components in three of the following broad roles:

Models – These are the business-oriented components that are intended to be displayed or manipulated by the application. They might be traditional business objects rehydrated from the DB, messages from a web service or anything else that has business meaning independent of presentation.

Views – WPF/Silverlight is a view framework and is thus intended to provided these components. Their role is to display something on the screen. Nothing more, nothing less.

View Models – This is a special type of model, intended to be an abstraction of the UI. You can think of it as a logical representation of the UI. It is “connected” to the view at runtime through databinding.

My guess is that you probably feel pretty comfortable with the idea of a Model or a View. You can picture them in your mind. But when it comes to View Models, things get foggy. It means that we need to have a lot more discussion around what our View Models look like. But, we cannot just discuss them abstractly. We must look at specific scenarios and see how ordinary design patterns interplay to create a meaningful model of the UI. In a few words, here’s my general philosophy and what I hope will become clear as we proceed:

The same OOD techniques you use to build your backend systems are used to construct your View Models.

To that end, I am hoping to put together several posts on the subject. I am planning to contact several of my previous clients with the intention of gaining permission to discuss small portions of their applications; or to discuss them at a very high level. I want to show specific problems and demonstrate how we used common design patterns to build a rich View Model. It is my hope that this will begin a richer discussion on the topic within our community.

Caliburn v1 Release Candidate

Rob Eisenberg — Sat, 13 Jun 2009 04:19:00 GMT

On Friday I published the Release Candidate for Caliburn. You can get it here. I’m hoping to only do bug fixes and a few minor changes between now and release. There have been quite a few important changes since the Beta:

Refactored assemblies for greater ease of use.
Implemented an Application base class that supports model-first development.
Introduced IViewStrategy and the View.Model attached property.
Added CommandSource triggers
Tweaked the implementation of Actions/Commands so that it performs better and is more intelligent
Updated dependencies on other OSS projects
Added a WPF version of the LOB Sample
Factored out mini-frameworks for the both the WPF and Silverlight LOB samples.
Implemented binding validation of hierarchical path notation.
Fixed many bugs throughout the framework.
Lots of other random features and improvements…

I hope that if you are building WPF or Silverlight applications you will take some time to evaluate Caliburn and give me some feedback.