Archive for the 'Software Design' Category

MVVM – Lambda vs INotifyPropertyChanged vs DependencyObject

Tuesday, January 26th, 2010

EDIT (12/6/2014): If you like C#, WPF, 3D, and Golf, check out my latest side project: https://www.youtube.com/watch?v=8pWq8vhZqbg
If you don’t like golf, don’t click the link!

It has been about 1.5 years since I last posted. When the market crashed I became fascinated by world of trading (and software) and applied a bit of WPF knowledge to some research and software for another blog. I have 20+ topics still pending for this blog, so there is plenty to write about in 2010 and beyond.

I have been using the MVVM pattern since the beginning of 2008. Since that time there have been plenty of complaints about INotifyPropertyChanged and how developers do not like using strings, etc. Last year several bloggers presented type-safe alternatives that used either reflection or lambda expressions. I really like the elegance and simplicity of the lambda expression, but many are quick to point out the poor performance (same for reflection). Unfortunately ‘poor performance’ says little about usefulness of an implementation. The performance needs to be quantified and compared against all implementations so that ‘poor’ can be put in perspective. Speed is not the only issue, as memory should be compared as well.

This article assumes the reader knows how to use INotifyPropertyChanged and DependencyObjects. (Note: the rest of this article will refer to the string implementation as INotifyPropertyChanged or just INotify). The lambda implementation that is used for the tests is as follows:

INotifyPropertyChanged with Lambda

public static class MvvmExtensions

{

    public static void Raise(this PropertyChangedEventHandler handler, object sender, Expression<Func<object>> expression)

    {

        if (handler != null)

        {

            if (expression.NodeType != ExpressionType.Lambda)

            {

                throw new ArgumentException(“Value must be a lamda expression”, “expression”);

            }

 

            var body = expression.Body as MemberExpression;

 

            if (body == null)

            {

                throw new ArgumentException(“‘x’ should be a member expression”);

            }

 

            string propertyName = body.Member.Name;

            handler(sender, new PropertyChangedEventArgs(propertyName));

        }

    }

}

public class DummyLambdaViewModel : INotifyPropertyChanged

{

    private string _dummyProperty;

 

    public string DummyProperty

    {

        get

        {

            return this._dummyProperty;

        }

        set

        {

            this._dummyProperty = value;

            OnPropertyChanged(() => this.DummyProperty);

        }

    }

 

    protected virtual void OnPropertyChanged(Expression<Func<object>> expression)

    {

        this.PropertyChanged.Raise(this, expression);

    }

 

    public event PropertyChangedEventHandler PropertyChanged;

}

Since many developers like to use a base view model class, if the property changed method is put in the base class then children will easily get the support for the lambda expression:

public abstract class ViewModelBase : INotifyPropertyChanged

{

    public ViewModelBase()

    {

    }

 

    protected virtual void OnPropertyChanged(Expression<Func<object>> expression)

    {

        this.PropertyChanged.Raise(this, expression);

    }

 

    public event PropertyChangedEventHandler PropertyChanged;

}

The derived class is now a bit more clean.

public class DummyLambdaViewModel : ViewModelBase

{

    private string _dummyProperty;

 

    public string DummyProperty

    {

        get

        {

            return this._dummyProperty;

        }

        set

        {

            this._dummyProperty = value;

            OnPropertyChanged(() => this.DummyProperty);

        }

    }

}

References
The lambda expression code was taken from the following blogs
http://www.jphamilton.net/post/MVVM-with-Type-Safe-INotifyPropertyChanged.aspx
http://blog.decarufel.net/2009/07/how-to-use-inotifypropertychanged-type_22.html
http://consultingblogs.emc.com/merrickchaffer/archive/2010/01/22/a-simple-implementation-of-inotifypropertychanged.aspx

Testing without WPF Bindings
There are essentially two components to lambda property change notification that cost performance. The first is the creation of the expression (such as () => this.DummyProperty). The second is the actual WPF binding infrastructure that affects all of the property change notification implementations. String property change events have virtually no ‘expression creation’ processing time since it is just a hard coded string (such as “DummyProperty”). By raising property change events when no bindings are attached (and thus no listener to the viewmodel’s PropertyChanged event), we can compare the ‘expression creation’ performance costs of the various property change implementations.

The lambda expressions are roughly 20 times slower than both string INotify and DependencyObjects when the WPF binding infrastructure is not included, giving us a measure of the raw performance cost of just raising the property change event. So far the performance cost of lambda expressions is living up to the ‘poor performance’ label.

Testing with WPF Bindings
Since the prior test is only part of the total processing required for property change notification, it is important to test again with a WPF binding in place so that the WPF binding system can work its magic against the property change events. By having a XAML element (such as a TextBlock) bind its Text property to a property of a viewmodel, WPF’s binding system will now be listening for the property change events and doing its own reflection and internal property management.

Once the WPF binding system is included in the performance tests, the lambda expression implementation drops from 20 times slower to only around 3 times slower. Even though using lambda expressions is slower than the alternatives, testing with the WPF binding system shows the performance hit is probably not as big as many have perceived it to be. Using  property change notification on a DependencyObject is the fastest technique since it was designed for that purpose, allowing the WPF binding system to listen to property change events with virtually no overhead and no reflection. However, like the INotify implementation, it uses a string for the property name identification.

Memory Usage
Performance is only half the story. In order to make proper design decisions, it is important to also know the memory characteristics of the various property change techniques. By using a profiler we can measure the number of objects created and destroyed, as well as bytes used during each property change request. The WPF binding system is included in the measurements.

The lambda expressions use almost 7 times the memory as INotify for each property change event, while the DependencyObject property change notification uses no memory at all (but the class itself uses memory). The following screenshot from the profiler shows the WPF binding system objects that are created and destroyed during the INotify event (1,000,000 events):

These are the objects and memory used for the lambda expression (1,000,000 events)

General Guidelines
With this performance and memory usage information we can summarize some loose guidelines for when to use each property change mechanism. Since the DispatcherObject is a WPF class, it has its own set of memory requirements to support

  • DispatcherObject: Use if speed critical and frequent property change events occur
  • INotifyPropertyChanged: Use if large numbers of viewmodels are created (it is more lightweight than DependencyObject), but speed is also important
  • Lambda Expressions: Use for type-safe property change notification when speed is not critical.

Test Application
You can download the application and code used for these tests here. The code is junk code, and is not a demonstration of proper design, testing, or MVVM principles.

Disclaimer
These tests were performed using a viewmodel with only one property. Performance can differ on viewmodels with many properties. Tests were also performed by raising the property change notifications in a loop. Real world performance can vary due to locality of reference.

Shout it

kick it on DotNetKicks.com

Stop Polluting the UI Thread – Use a DelegateMarshaler

Tuesday, July 22nd, 2008

EDIT (12/6/2014): If you like C#, WPF, 3D, and Golf, check out my latest side project: https://www.youtube.com/watch?v=8pWq8vhZqbg
If you don’t like golf, don’t click the link!

Introduction

Update – ThreadBarrier was a poorly chosen name, use the latest DelegateMarshaler implementation instead.

With the advent of multi-core processors becoming standard in desktop PCs, it is clear we are on the verge of a shift in which high level software is designed and developed. First there was Object Oriented programming, then design patterns, and now there is multithreading. Multithreading has been around for decades in high end computing, but due to the now wide availability of multiple cores in a standard PC or laptop, it is only now that it is beginning to gain mainstream attention. There is a lot of work to do for tools, frameworks, and patterns to simplify the design and debugging of multithreading programs. While Microsoft has been working diligently to improve their tools (Visual Studio) and frameworks (Task Parallel Library) to bring multithreading into the mainstream, there is not yet enough guidance and information on the internet about proper threading techniques and design patterns.

This is where the ‘ThreadBarrier’ pattern comes in. Ultimately it is a way to help simplify the interaction between the UI and worker threads. A ThreadBarrier is an encapsulation of thread execution inside a class such that it is not exposed to the outside world. Rather, external events are first posted to the UI thread so any listener (on the UI thread) does not have to worry about threading issues. Like any pattern, there are times where it is ideal to use and there are times where it does not apply. Use at your own discretion.

Background

It seems that nearly every introductory threading example on the internet consists of a button click that starts a thread that performs some operation in a worker thread in the UI code behind. While simple examples are good, this immediately introduces a developer to starting threads In UI code and thinking that such techniques are normal.

The Problem

The problem is that the only way most developers know how to get data back to the UI thread is to use a UI control to post back the information. In case you are new to threading: the golden rule is that all UI controls (windows, textboxes, progressbars, etc.) can only be accessed from the thread that created them (the UI thread of course). This means a worker thread cannot do myTextBox.Text=”asdf” otherwise a cross-thread exception will be thrown. Controls provide a mechanism for executing a method on the UI thread (Control.Invoke, Control.BeginInvoke, Dispatcher.Invoke, Dispatcher.BeginInvoke).

WinForms example:

delegate void SetStartDelegate(bool enabled);

 

public void SetStartEnabled(bool enabled)

{

if (this.InvokeRequired == false)

{

this.buttonStart.Enabled = enabled;

}

else

{

this.Invoke(new SetStartDelegate(SetStartEnabled), new object[] { enabled });

}

}

WPF example:

delegate void SetStartDelegate(bool enabled);

 

public void SetStartEnabled(bool enabled)

{

if (this.Dispatcher.CheckAccess() == true)

{

this.buttonStart.IsEnabled = enabled;

}

else

{

this.Dispatcher.Invoke(DispatcherPriority.Send, new SetStartDelegate(SetStartEnabled), enabled);

}

}

There are tricks to make this a bit cleaner, but that is the common way to update the UI from any thread.

The combination of the Control’s UI thread rule and a Control’s ability to invoke on the UI thread essentially handcuffs developers into mixing threads with the UI and trying to make it work. Perhaps some have tried to be smart and hide the threads away deep in non-UI code to keep the UI clean. Those developers probably end up with the following questions (at least I did):

“How the heck do you get a control for invoking that deep in the execution and far away from the UI code? And more importantly, why does it have to be this way? There has to be a better way.”

The Answer

There is a better way, and it involves a SynchronizationContext. Rather than use a Control to post execution back to the UI, a SynchronizationContext provides this same capability without the UI Control requirement. Since a fantastic CodeProject article already covers the SynchronizationContext in depth, a summary will only be described here.

SynchronizationContext Overview

-SynchronizationContext is an abstract base class for:
-WindowsFormsSynchronizationContext
-DispatcherSynchronizationContext
-WinForms automatically creates an instance of WindowsFomsSynchronizationContext for a WinForms UI thread.
-WPF automatically creates an instance of DispatcherSynchronizationContext for a WPF UI thread.
-Static property AsyncOperationManager.SynchronizationContext gets the SynchronizationContext for the calling thread: WindowsFormsSynchronizationContext in WinForms and DispatcherSynchronizationContext in WPF.
-SynchronizationContext provides two methods (Send and Post) for synchronous or asynchronous method invocation.
-Getting AsyncOperationManager.SynchronizationContext on a non-UI thread (such as in a console app or worker thread) returns the base SynchronizationContext class that just invokes a method on the calling thread when Send is used, and calls a method on a ThreadPool thread when Post is used.

Introducing the ThreadBarrier ‘Pattern’

The ThreadBarrier pattern consists of a non-UI class encapsulating and executing a worker thread and always raising its events on the UI thread using a SynchronizationContext. The worker thread execution should never leave the class via events. Data and objects within the class may be operated upon by the worker thread but all external events must be called on the UI thread. If this technique is correctly followed then the listening UI code does not need to worry about thread checks and delegate posting.

Implementing a ThreadBarrier’ (.NET 2.0)

A ThreadBarrier can be implemented as an abstract class so that derived classes automatically inherit the necessary functionality to support the pattern.

public abstract class ThreadBarrier

{

private SynchronizationContext _synchronizationContext;

 

protected ThreadBarrier()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

}

The SyncronizationContext must be stored as a field so that it can be used by the worker thread in the derived class. Since the static AsyncOperationManager.SynchronizationContext property is called in the constructor, a critical requirement of properly using a ThreadBarrier derived class is that it must be created on the thread in which events want to be raised. In other words, create the class on the UI thread so that the UI’s context is captured. A worker thread can then use this context to post the methods that raise events back to the UI. The following protected method can be used for posting OnXXX methods:

public void Post<T>(Action<T> raiseEventMethod, T e)

where T : EventArgs

{

if (this._synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem(delegate { raiseEventMethod(e); });

}

else

{

this._synchronizationContext.Post(delegate { raiseEventMethod(e); }, null);

}

}

For an event such as:

 

public event EventHandler Stopped;

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

A ThreadBarrier derived class simply posts events to the UI in this way:

 

Post(OnStopped, EventArgs.Empty);

A small example of a class implementing a ThreadBarrier would look like:

 

public class WeatherChecker : ThreadBarrier

{

public event EventHandler<WeatherEventArgs> TemperatureChanged;

public event EventHandler<WeatherEventArgs> HumidityChanged;

public event EventHandler<WeatherEventArgs> WindChanged;

public event EventHandler Stopped;

 

private bool _isStopRequested;

private Random _random;

 

public WeatherChecker()

{

this._isStopRequested = false;

 

//used for generating random weather information

this._random = new Random((int)DateTime.Now.Ticks);

}

 

public void Start()

{

Thread thread = new Thread(new ThreadStart(CheckWeather));

thread.IsBackground = true; //prevents thread from keeping app alive when app is closed

thread.Start();

}

 

private void CheckWeather()

{

while (this._isStopRequested == false)

{

Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

Post(OnWindChanged, new WeatherEventArgs(Rand(15f)));

Post(OnHumidityChanged, new WeatherEventArgs(Rand(100f)));

 

//Updates roughly 4 times per second

Thread.Sleep(250);

}

 

Post(OnStopped, EventArgs.Empty);

}

 

public void RequestStop()

{

this._isStopRequested = true;

}

 

private float Rand(float max)

{

return (float)this._random.NextDouble() * max;

}

 

protected virtual void OnTemperatureChanged(WeatherEventArgs e)

{

if (this.TemperatureChanged != null)

{

this.TemperatureChanged(this, e);

}

}

protected virtual void OnHumidityChanged(WeatherEventArgs e)

{

if (this.HumidityChanged != null)

{

this.HumidityChanged(this, e);

}

}

protected virtual void OnWindChanged(WeatherEventArgs e)

{

if (this.WindChanged != null)

{

this.WindChanged(this, e);

}

}

protected virtual void OnStopped(EventArgs e)

{

if (this.Stopped != null)

{

this.Stopped(this, e);

}

}

}

 

The key points are:
-WeatherChecker derives from ThreadBarrier
-The worker thread is started inside this non-UI WeatherChecker class.
-The WeatherChecker should be created on the UI thread.

Now the UI code is very clean and does not have to worry about threads:

public partial class Form1 : Form

{

private WeatherChecker _weatherChecker;

 

public Form1()

{

InitializeComponent();

}

 

private void buttonStart_Click(object sender, EventArgs e)

{

this.buttonStart.Enabled = false;

this.buttonStop.Enabled = true;

 

this._weatherChecker = new WeatherChecker();

this._weatherChecker.TemperatureChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_TemperatureChanged);

this._weatherChecker.HumidityChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_HumidityChanged);

this._weatherChecker.WindChanged += new EventHandler<WeatherEventArgs>(_weatherChecker_WindChanged);

this._weatherChecker.Stopped += new EventHandler(_weatherChecker_Stopped);

 

this._weatherChecker.Start();

}

 

private void buttonStop_Click(object sender, EventArgs e)

{

this._weatherChecker.RequestStop();

}

 

void _weatherChecker_TemperatureChanged(object sender, WeatherEventArgs e)

{

this.labelTemperature.Text = String.Format(“{0:F1} C”, e.Value);

}

 

void _weatherChecker_HumidityChanged(object sender, WeatherEventArgs e)

{

this.labelHumidity.Text = String.Format(“{0:F0}%”, e.Value);

}

 

void _weatherChecker_WindChanged(object sender, WeatherEventArgs e)

{

this.labelWind.Text = String.Format(“{0:F0} mph”, e.Value);

}

 

????????

void _weatherChecker_Stopped(object sender, EventArgs e)

{

this.buttonStop.Enabled = false;

this.buttonStart.Enabled = true;

 

this._weatherChecker = null;

}

}

Implementing a ThreadBarrier (.NET 3.5)

Since the requirement of deriving from a ThreadBarrier class is not ideal, in .NET 3.5 we can use extension methods to help us do the work.

public static class ThreadBarrierExtensions

{

public static void Post<T>(this SynchronizationContext synchronizationContext, Action<T> raiseEventMethod, T eventArgs)

where T : EventArgs

{

if (synchronizationContext == null)

{

ThreadPool.QueueUserWorkItem((e) => raiseEventMethod((T)e), eventArgs);

}

else

{

synchronizationContext.Post((e) => raiseEventMethod((T)e), eventArgs);

}

}

}

 

Now the WeatherChecker class does not have to derive from a ThreadBarrier (but it now has to do the work in its constructor of saving a reference to the SynchronizationContext, the task previously left for the abstract ThreadBarrier class).:

 

public class WeatherChecker

{

private SynchronizationContext _synchronizationContext;

 

public WeatherChecker()

{

this._synchronizationContext = AsyncOperationManager.SynchronizationContext;

}

Using an extension method on the SynchronizationContext allows us to post the OnXXX method:

this._synchronizationContext.Post(OnTemperatureChanged, new WeatherEventArgs(Rand(30f)));

 

Using Lambda expressions also simplifies the handling of the events in the UI code:

 

this._weatherChecker.TemperatureChanged += (weatherChecker, weatherEventArgs) =>

{

this.labelTemperature.Content = String.Format(“{0:F1} C”, weatherEventArgs.Value);

};

Conclusion

The ThreadBarrier technique is an easy way to simplify the use of a worker thread and how it interacts with the UI. It is not the silver bullet for multithreading, but it does offer a way to think of a thread as an ‘object’ and hide the threading complexities. The UI and worker thread can be separated even further by designing a ThreadBarrier class to do nothing but handle events from other threading code (such as in a library that you do not have the code) and propagate just these events to the UI. This truly allows the business ‘logic’ to be free of any UI dependencies.

Samples

  • ThreadBarrier Technique #1: Subclassing an existing worker thread class
  • ThreadBarrier Technique #2: Using extension methods on a SynchronizationContext
  • ThreadBarrier Technique #3: Deriving from a ThreadBarrier
  • ThreadBarrier Technique #4: Creating an instance of a ThreadBarrier
  • ThreadBarrier Technique #5: Creating an adapter class to propagate events
  • Download all Samples

    UPDATE: The DelegateMarshaler has been revisited with a description of the 5 techniques in the sample.

    kick it on DotNetKicks.com

    WPF Application Design and Architecture

    Tuesday, July 22nd, 2008

    EDIT (12/6/2014): If you like C#, WPF, 3D, and Golf, check out my latest side project: https://www.youtube.com/watch?v=8pWq8vhZqbg
    If you don’t like golf, don’t click the link!

    As I have been studying WPF in the past several months, I have come to at least one conclusion: The power and flexibility of WPF comes with a subtle cost. This cost is that there are 100x more ways to design an application in WPF than there is in WinForms; therefore there are 100x more ways to shoot yourself in the foot. Fortunately, once one goes through the failures and learning cycle of WPF, it becomes much easier to design flexible and scalable applications in WPF than doing so in WinForms.

    The purpose of this post is to illustrate the various ways a feature or WPF application can be designed.

    This post:
    -Provides a peek into the vast world of WPF application designs.
    -Provides sample code for each design
    -Is for beginner/intermediate level WPF application developers.
    -Is not a ‘best practices’ guide, it just provides a set of examples to help readers understand how classes and interaction between objects can be designed.
    -Is not a ‘How-To.’ The examples are extremely contrived and few WPF features are demonstrated.

    Before continuing I suggest reading the following articles:
    -Dr. WPF’s A Project Needs Structure
    -Introduction to Model/View/ViewModel
    -100 Model/View/ViewModels of Mt. Fuji
    -Model-View-ViewModel pattern example
    -ViewModel example
    -Advantages and disadvantages of M-V-VM
    -UML diagram of M-V-VM pattern
    -WPF Patterns
    -Dan Crevier’s DataModel-View-ViewModel Series
    -DataModel and VIewModel

    I also recommend studying the source and design of the following applications:
    -Family.Show
    -SceReader

    If all of these concepts are new to you, it can be a bit overwhelming. It is a lot of information and concepts to absorb. Hopefully the samples provided in this post can make it easier to understand how these concepts can come into play in a real-world application. Four designs will be demonstrated, starting from an extremely simple design all the way to one that uses DataModel-View-ViewModel. Each sample has the same features to make it easier to follow along the evolution of the design.

    The features that are demonstrated are as follows:
    -Two buttons allow a user to find currently loaded assemblies and types
    -A textbox allows the search to be filtered.
    -The results are displayed in a listbox

    Download the samples: WPFDesigns
    I recommend browsing the source and following along as each sample and design is explained.

    Design #1

    For such a simple application, it really does not take much to implement the solution using just a window with some buttons and a ListBox on it. When a button is clicked, a handler can call a method and update the listbox’s ItemsSource directly.

    public void ShowTypes_Click(object sender, RoutedEventArgs e)
    {
    this.ResultsListBox.ItemsSource = FindTypeNames();
    }

    1. A button is clicked and handled in Window1’s code behind.
    2. The loaded types are retrieved.
    3. The ListBox’s ItemsSource is updated

    Design #2

    In this sample the buttons and textbox are moved onto their own user control, while the ListBox is moved to its own user control as well. Breaking up a UI into modular components allows the UI to remain simple as many features are added, and forces the logic handling to be more modular as well.

    <UserControl x:Class=”WpfDesigns2.Controls.OperationsUserControl”
    xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation
    xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml
    DataContext=”{Binding RelativeSource={RelativeSource Self}}”>
    <Grid>
    <StackPanel>
    <Button Click=”ShowAssemblies_Click”>Show Assemblies</Button>
    <Button Click=”ShowTypes_Click”>Show Types</Button>
    <TextBlock>Match:</TextBlock>
    <TextBox Width=”80″ Text=”{Binding Path=MatchText}”/>
    </StackPanel>
    </Grid>
    </UserControl>

    Now that each user control is handling its own events there needs to be some way to get the results from one user control to the other. Since the Window1 is hosting both user controls, in this sample we will make it listen to an operation complete event that contains the results, and then send those results to the user control with the ListBox so it can be updated.

    1. The button click is handled in the Operations user control.
    2. Using the MatchText variable and a ReflectionHelper object that exists in the Operations user control, the assemblies or types are retrieved.
    3. The user control raises an event letting listeners know the results are complete.
    4. Window1 handles the event and sends the results to the ReflectionResults property of the user control with the ListBox.
    5. Since the ListBox is bound to the ReflectionResults dependency property, the ListBox UI is updated automatically.

    Design #3

    This sample takes the design a step further and breaks the UI from the logic. You can think of the user controls as the View and the logic as the Model. A manager called ApplicationManager was designed to contain all of the objects in the model. This manager is created in Window1’s XAML:

    <ObjectDataProvider x:Key=”ApplicationManager” ObjectType=”{x:Type local:ApplicationManager}” />

    Since Window1 contains the manager in its resources collection, it can pass on the manager’s child models to each respective user control:

    <controls:OperationsUserControl
    Grid.Column=”0″
    x:Name=”OperationsControl”
    DataContext=”{Binding Source={StaticResource ApplicationManager}, Path=ReflectionHelper}”/>
    <controls:ReflectionResultsUserControl
    Grid.Column=”1″
    x:Name=”ReflectionDisplayControl”
    DataContext=”{Binding Source={StaticResource ApplicationManager}, Path=ReflectionResults}”/>

    Now each user control’s DataContext is set to an object from the Model layer, so that the UI elements can bind to a single model element. When the user control needs to get its model object, it can do so in the following way:

    private ReflectionHelper ReflectionHelper
    {
    get
    {
    return this.DataContext as ReflectionHelper;
    }
    }

    A button click in the handler is as easy as:

    public void ShowTypes_Click(object sender, RoutedEventArgs e)
    {
    this.ReflectionHelper.FindTypes();
    }

    In this sample the ApplicationManager is handling listening for the results from one model and passing the data on to the results model. This separates the logic from the views. Since the ReflectionResultsUserControl is bound to the Results property on the results model, it gets updated automatically when the ApplicationManager updates the results model. At this stage the UserControls are doing virtually nothing and the model layer is doing all of the work (which is ideal).

    1. The button click is handled in the OperationsUserControl.
    2. The FindTypes or FindAssemblies method is called on the user control’s model element.
    3. The reflection helper model element does some reflection work
    4. When the work is complete an event is raised
    5. The ApplicationManager listening for the event updates the ReflectionResults model element.
    6. Since the ReflectionResultsUserControl’s ListBox is bound to the Results property of the ReflectionResults model element, the ListBox is updated automatically.

    Design #4

    At this point we have probably taken the samples as far as they need to go. However, to demonstrate one way the DataModel-View-ViewModel pattern can be implemented, sample #4 takes the design to the next level. Since the other DataModel-View-ViewModel articles already do a great job explaining the concepts, I will just describe the design for sample #4. Let’s start with the diagram:

    1. Using a RoutedCommand the OperationsView handles the button click command.
    2. The view calls into its view model to perform an operation.
    3. Since the OperationsViewModel was storing the MatchText data, it can call into its model (ReflectionHelper) to find types or assemblies.
    4. The ReflectionHelper model retrieves the matching types or assemblies.
    5. The ReflectionHelper raises its operations complete event
    6. The ApplicationManager handles the event and updates the ReflectionResults model.
    7. The ReflectionResults model raises a results changed event
    8. The ReflectionResultsVewModel handles the event and puts the results data into a format suitable for its view.
    9. Since the ListBox in the ReflectionResultsView is bound to the ObservableCollection in its respective view model, the ListBox is updated automatically.

    For such a small application this design is overkill. However, as applications grow in size and complexity, the DataModel-View-ViewModel pattern keeps the overall design simple and minimizes dependencies. It also has the added benefit of making all of the various modules much easier to test, which is obviously crucial to the success of any large piece of software.

    One interesting aspect of the DM-V-VM is how well the view can be abstracted from the rest of the application. For example, in this sample a new class call ApplicationViewState was created to hold the view models that represent the views. A DataTemplate allows us to represent the view model in any way we want:

    <DataTemplate DataType=”{x:Type viewModels:OperationsViewModel}”>
    <!–Sets the view model as the data context–>
    <views:OperationsView DataContext=”{Binding}” />
    </DataTemplate>

    In the main window a ContentPresenter is used to represent a ‘place holder’ for its content which is specified to be one of the view models:

    <ContentPresenter
    Grid.Column=”0″
    Content=”{Binding Source={StaticResource ApplicationManager}, Path=ViewState.LeftSideView}”/>
    <ContentPresenter
    Grid.Column=”1″
    Content=”{Binding Source={StaticResource ApplicationManager}, Path=ViewState.RightSideView}”/>

    By swapping the view models in the ApplicationViewState, the views automatically follow their respective view model. This is a crude demonstration of a data driven UI.

    Disclaimer: Design #4’s sample is not a perfect implementation of the DM-V-VM pattern. I have seen it implemented in various different ways. It usually depends on the requirements of the particular application. As far as I can tell there is also no difference between what people call a DataModel and a Model. Since many WPF applications work with a data layer of some sort such as a database, they call it the DataModel. In this last sample I could have easily just called the ReflectionHelper and ReflectionResults Models (I think I did a few times anyways).

    A Word of Warning: If you are new to WPF, attempting to implement DM-V-VM for your application is extremely difficult. There are many ‘gotchas’ along the way that put major roadblocks in the way of solving problems. Most of these are WPF specific. Your best source of help is the MSDN WPF Forum.

    In the real world, applications are usually a mix of all four of these designs. No single design fits every application. It is up to you to learn from your mistakes in order to learn how to design and develop simple, flexible, scalable applications. :) No matter how experienced you get, there is always more to learn!

    Download the samples: WPFDesigns

    All questions, comments, and criticism are welcome!