Contents
Introduction
Probably the most often discussed topic around WPF and Silverlight in the last year or two has been the MVVM (Model View View Model) pattern. MVVM has surfaced as a candidate replacement for similar architectural patterns such as the MVC and MVP patterns, because it leverages specific features of WPF and Silverlight, most notably the data binding infrastructure, to deepen the separation
of the view layer from the rest of an application's layers. This has several benefits, including allowing interactive designers to focus exclusively on the user interface (UI), concurrent development of application layers, and easier testability.
The mechanisms that make MVVM so effective can also be applied to a secondary pattern, one that I have called the Model Thread View Thread pattern (MTVT). It is an approach that may be seen as extending the principles behind MVVM. The MTVT pattern is an architectural pattern used for explicit demarcation of the view and view model via disparate threads of execution. In summary, its main characteristics are that it is comprised of two distinct threads of execution, (one for the view and one for the other application layers), and that cross thread communication occurs transparently over familiar WPF and Silverlight features; such as events (INotifyPropertyChanged, INotifyCollectionChanged etc.) and commands.
In the proof of concept download, I have provided:
- A weak referencing event management system that maintains thread affinity with subscribers.
- A command class that invokes handlers on an application's model thread.
- A synchronized ObservableCollection that allows its collection changed event to be raised on the thread where subscription took place.
- And a
ViewModelBase class that raises property changes on the subscribers thread.
MTVT is specifically focused on providing for a non-presentation layer centric approach. In MTVT, the execution of model logic is separated from UI controls using an asynchronous threading model.
MTVT displaces the traditional UI centric approach in which the UI thread is the primary thread, and where all activity occurs there by default.
Why a new approach?
MTVT is designed to make use of specific capabilities of WPF and Silverlight to better separate the view or presentation layer at run-time, which in turn provides greater assurance of UI responsiveness and, in the case of Silverlight, facilitates such things as synchronous WCF communication.
.NET GUI applications are traditionally UI thread centric. For example, a developer may provide an event handler for an event, and if the handler is deemed to be a long running activity, then the developer will write code to spin off the work to a worker thread. It is, however, common that the developer will neglect to write the asynchronous code, because the execution time of the handler is underestimated, or it is seen as too laborious to write the code at the time. The ramifications of not doing so, usually don't present themselves until later.
If, on the other hand, the developer takes the approach of invoking all state changes on the UI thread, then not only can we end up with lots of ugly boiler plate code, but we can end up degrading an application's performance if we're not careful.
MTVT, in part, addresses this haphazard approach to delegation. It reduces the need for repetitive coding activities around controlling concurrency, and it alleviates the need to explicitly invoke changes in the UI from the model. Also, explicit designation of a single model thread may help to reduce concurrency issues, which are otherwise inevitable when working with multiple child threads.
Another benefit is that model logic becomes more scalable, as the introduction of new functionality won't slow the UI.
These days we see lots of tools emerging that assist in transparently parallelizing work, (such as PLINQ and TPL). Infrastructure for parallelization will become evermore prevalent, and such technologies focus on abstracting the mechanism for retrieving data, using e.g., LINQ, and focusing on the what not the how. This proof of concept attempts to do the same, in that the mechanisms for raising events, performing commands, and updating collections remain the same.
Background
Some time ago, back in 2008, I published an article in which I describe how to perform blocking WCF service calls (synchronous at the user code level) in Silverlight, thereby removing the asynchronous requirement; which can lead to spaghetti code. It describes a reactor implementation to provide a synchronous interface for the Silverlight asynchronous API. Since then I’ve been surprised by the frequent emails and messages I have received by users that don’t really understand the approach necessary to make it all work fluidly. Many contend that even though it is possible, as I demonstrate how to do it, they have a hard time reconciling the notion that the UI thread should not necessarily be the 'driving' thread. And, I can kind of see why.
MVVM has shown that in most cases, adequate view separation is attainable. However, because both WPF and Silverlight rely on thread affinity with the UI thread, issues around threading occur, and can hinder the application of the pattern. This has lead me to devise MTVT. This pattern lends itself quite naturally to both Silverlight and WPF because of the binding, commanding, and event infrastructure. And as we shall see, I demonstrate how the features can be put to work transparently to support the pattern. There's nothing new to do, (in fact there is less to do), and we don't need to radically change the way we work.
Sample Application
Requirements:
The sample is a rudimentary Silverlight application, which demonstrates the commanding, events, and collection that makes the dual thread approach possible.
It consists of a single page, with a single interactive component: a button.
Figure: Demonstration application.
The "Fire view model command" button has an attached property, which is the Prism Click.Command property.
<Content="Fire view model command"
cal:Click.Command="{Binding TestCommand}" />
When the button is clicked, an execution handler located in the MainPageViewModel is invoked on the model thread, as shown in the following excerpt:
void OnTestCommandExecute(object obj)
{
Message = "Processing command in view model \n (sleeping to show UI doesn't lock)";
Thread.Sleep(2000);
string newItem = "Test " + ++clickCount;
exampleCollection.Add(newItem);
TestString = newItem;
Message = string.Empty;
}
The Message property of the view model is modified. This property change occurs on the view model thread,
yet the UI is informed of the change via the UISynchronizationContext, which invokes the change handler on the UI thread,
as not to raise an invalid cross thread exception.
Figure: View model is put to sleep, yet the view remains responsive.
Once the model thread is finished sleeping, we add an item to our custom observable collection, which safely invokes its CollectionChanged
event handlers on the UI thread; the thread where the Silverlight data binding infrastructure subscribed to the event.
Figure: Item safely added to the collection.
This demonstrates that we are indeed able to separate the UI thread from the model thread.
There are some subtleties to the implementation. For example, you may be wondering how we are able to handle the CanExecute event handler,
which requires the method to return a result; thereby requiring the UI thread to be blocked. Well, in Silverlight, blocking the UI thread is not an option
because the event loop is serviced by the UI thread. But, we can still achieve the 'enabled/disabled' functionality by using a callback.
This can be seen in the following excerpt from the ModelCommand class, which makes use of Prism's WeakEventHandlerManager.
ModelCommand Class
public class ModelCommand<T> : ICommand, IActiveAware
{
readonly Action<T> executeMethod;
readonly Func<T, bool> canExecuteMethod;
List<WeakReference> canExecuteChangedHandlers;
bool active;
public ModelCommand(Action<T> executeMethod, Func<T, bool> canExecuteMethod)
{
if (executeMethod == null && canExecuteMethod == null)
{
throw new ArgumentNullException("executeMethod");
}
this.executeMethod = executeMethod;
this.canExecuteMethod = canExecuteMethod;
}
</span> /// Indicates that a can execute handler has provided a result.
/// <span class="code-SummaryComment"></summary>
</span> volatile bool canExecuteResultReceived;
/// <span class="code-SummaryComment"><summary>
</span> /// Indicates whether this command can be executed.
/// <span class="code-SummaryComment"></summary>
</span> volatile bool canExecuteResult;
public bool CanExecute(T parameter)
{
if (canExecuteMethod == null)
{
return true;
}
if (canExecuteResultReceived)
{
var result = canExecuteResult;
canExecuteResultReceived = false;
return result;
}
/* We dispatch the call to determine if the command
* can execute in a non blocking manner.
* This is because we can't block the UI thread without causing a lockup. */
ModelSynchronizationContext.Instance.InvokeWithoutBlocking(
delegate
{
canExecuteResult = canExecuteMethod(parameter);
canExecuteResultReceived = true;
/* Once we get the real result we can signal to the UI
* that the command can or can't execute. If canExecuteResult is not null,
* that result will be returned and canExecuteResult will be set to null. See above. */
OnCanExecuteChanged();
});
return false;
}
public void Execute(T parameter)
{
if (executeMethod == null)
{
return;
}
ModelSynchronizationContext.Instance.InvokeWithoutBlocking(
() => executeMethod(parameter));
}
// Shortened for clarity.
}
Here we see that the CanExecute method does not block the caller when invoking the CanExecute event handler on the model thread.
But, what it does do is invokes the handler without blocking, and signals when a result has been obtained by calling the OnCanExecuteChanged method.
This then triggers the CanExecute method to be called a second time. And for the second call the value of canExecuteResultReceived
is used to signal that this time around we have a value, and thus the canExecuteResult is supplied, and the flag reset.
Figure: The ModelCommand makes use of the ModelSynchronizationContext in order to invoke the Execute and CanExecute
event handlers on the model thread.
When a command is executed, as when the button is clicked in the sample application, we see that the event handler is invoked using the ModelSynchronizationContext.
This occurs in a non blocking call, and thus prevents the UI from locking up.
Synchronization Infrastructure
So, we've looked at the sample application. Now let's explore the infrastructure in a bit more detail.
We shall start with the synchronization infrastructure, and look at how it is used to maintain two separate threads of execution, and in particular the
ISynchronizationContext interface, which defines the standard functionality of all synchronization contexts.
ISynchronizationContext Interface
This interface specifies that an Action or SendOrPostCallback may be queued for invocation,
in either a blocking or non-blocking manner.
Figure: ISynchronizationContext class diagram.
There are two implementations of this interface. They are the ModelSynchronizationContext, and the UISynchronizationContext.
Both are tasked with invoking delegates on either the model thread, or UI thread respectively.
ModelSynchronizationContext Class
The ModelSynchronizationClass uses a dedicated thread to invoke a queue of actions or CallbackReferences.
This presents a familiar producer and consumer problem; easily solved with an AutoResetEvent,
which is used to signal when an item has been added to the queue. Thus, we do not need to resort to using a polling mechanism.
The following excerpt is taken from the ModelSynchronizationContext class:
public class ModelSynchronizationContext : ISynchronizationContext
{
volatile bool stopRunning;
readonly Queue<CallbackReference> callbacks = new Queue<CallbackReference>();
readonly object callbacksLock = new object();
readonly AutoResetEvent consumerThreadResetEvent = new AutoResetEvent(false);
internal void Stop()
{
stopRunning = true;
}
class CallbackReference
{
public SendOrPostCallback Callback { get; set; }
public object State { get; set; }
}
#region Singleton implementation
ModelSynchronizationContext()
{
threadOfCreation = new Thread(
delegate(object o)
{
while (!stopRunning)
{
ConsumeQueue();
consumerThreadResetEvent.WaitOne();
}
});
threadOfCreation.Start();
}
public static ModelSynchronizationContext Instance
{
get
{
return Nested.instance;
}
}
</span> /// Inner class for full lazy loading of singleton.
/// <span class="code-SummaryComment"></summary>
</span> class Nested
{
static Nested()
{
}
internal static readonly ModelSynchronizationContext instance = new ModelSynchronizationContext();
}
#endregion
readonly Thread threadOfCreation;
/// <span class="code-SummaryComment"><summary>
</span> /// Gets the model thread.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><value>The thread.</value>
</span> internal Thread Thread
{
get
{
return threadOfCreation;
}
}
/// <span class="code-SummaryComment"><summary>
</span> /// Invokes the callback without blocking. Call will return immediately.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="callback">The callback to invoke.</param>
</span> /// <span class="code-SummaryComment"><param name="state">The state to pass during the callback invocation.</param>
</span> public void InvokeWithoutBlocking(SendOrPostCallback callback, object state)
{
lock (callbacksLock)
{
callbacks.Enqueue(new CallbackReference { Callback = callback, State = state });
}
consumerThreadResetEvent.Set();
}
/// <span class="code-SummaryComment"><summary>
</span> /// Invokes the specified action without blocking. Call will return immediately.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="action">The action to invoke.</param>
</span> public void InvokeWithoutBlocking(Action action)
{
lock (callbacksLock)
{
callbacks.Enqueue(new CallbackReference { Callback = o => action() });
}
consumerThreadResetEvent.Set();
}
/// <span class="code-SummaryComment"><summary>
</span> /// Invokes the specified callback and blocks until completion.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="callback">The callback to invoke.</param>
</span> /// <span class="code-SummaryComment"><param name="state">The state to pass during invocation.</param>
</span> /// <span class="code-SummaryComment"><exception cref="InvalidOperationException">
</span> /// Occurs if call made from the UI thread.<span class="code-SummaryComment"></exception>
</span> public void InvokeAndBlockUntilCompletion(SendOrPostCallback callback, object state)
{
RaiseExceptionIfUIThread();
AutoResetEvent innerResetEvent = new AutoResetEvent(false);
var callbackState = new CallbackReference { Callback = callback, State = state};
lock (callbacksLock)
{
var processedHandler = new EventHandler<InvokeCompleteEventArgs>(
delegate(object o, InvokeCompleteEventArgs args)
{
if (args.CallbackReference == callbackState)
{
innerResetEvent.Set();
}
});
invokeComplete += processedHandler;
callbacks.Enqueue(callbackState);
}
consumerThreadResetEvent.Set();
innerResetEvent.WaitOne();
}
/// <span class="code-SummaryComment"><summary>
</span> /// Invokes the specified callback and blocks until completion.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="action">The action to invoke.</param>
</span> /// <span class="code-SummaryComment"><exception cref="InvalidOperationException">
</span> /// Occurs if call made from the UI thread.<span class="code-SummaryComment"></exception>
</span> public void InvokeAndBlockUntilCompletion(Action action)
{
RaiseExceptionIfUIThread();
var itemResetEvent = new AutoResetEvent(false);
var callbackReference = new CallbackReference {Callback = o => action()};
lock (callbacksLock)
{
var processedHandler = new EventHandler<InvokeCompleteEventArgs>(
delegate(object o, InvokeCompleteEventArgs args)
{
if (args.CallbackReference == callbackReference)
{
itemResetEvent.Set();
}
});
invokeComplete += processedHandler;
callbacks.Enqueue(callbackReference);
}
consumerThreadResetEvent.Set();
itemResetEvent.WaitOne();
}
void RaiseExceptionIfUIThread()
{
if (!UISynchronizationContext.Instance.InvokeRequired)
{
throw new InvalidOperationException(
"Blocking the UI thread may cause the application to become unresponsive.");
}
}
void ConsumeQueue()
{
while (callbacks.Count >
Notice that in either of the InvokeAndBlockUntilCompletion method overloads, to invoke an action, and then block until the action is complete,
we use another AutoResetEvent named itemResetEvent. Whenever the queue is being consumed by our model thread, as each action is completed,
the invokeComplete event is raised, which allows the anonymous handlers (in the InvokeAndBlockUntilCompletion methods),
to test whether the action invoked is the one that is being waited on. If so, this indicates that the action has been invoked, and that the method is free to return.
UISynchronizationContext Class
The other ISynchronizationContext implementation is the UISynchronizationContext.
It makes use of a Dispatcher and a DispatcherSynchronizationContext to do the heavy lifting for us.
In order to perform blocking calls on the UI thread we use a DispatcherSynchronizationContext.
I often see people wondering how to perform blocking calls with the Dispatcher, and here's how it's done: take a Dispatcher
and instantiate a DispatcherSynchronizationContext, then call context.Post(callback, state);
</span>/// Singleton class providing the default implementation
/// for the <span class="code-SummaryComment"><see cref="ISynchronizationContext"/>, specifically for the UI thread.
</span>/// <span class="code-SummaryComment"></summary>
</span>public partial class UISynchronizationContext : ISynchronizationContext
{
DispatcherSynchronizationContext context;
Dispatcher dispatcher;
#region Singleton implementation
static readonly UISynchronizationContext instance = new UISynchronizationContext();
/// <span class="code-SummaryComment"><summary>
</span> /// Gets the singleton instance.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><value>The singleton instance.</value>
</span> public static ISynchronizationContext Instance
{
get
{
return instance;
}
}
#endregion
public void Initialize()
{
EnsureInitialized();
}
readonly object initializationLock = new object();
void EnsureInitialized()
{
if (dispatcher != null && context != null)
{
return;
}
lock (initializationLock)
{
if (dispatcher != null && context != null)
{
return;
}
try
{
#if SILVERLIGHT
dispatcher = System.Windows.Deployment.Current.Dispatcher;
#else
dispatcher = Dispatcher.CurrentDispatcher;
#endif
context = new DispatcherSynchronizationContext(dispatcher);
}
catch (InvalidOperationException)
{
/* TODO: Make localizable resource. */
throw new ConcurrencyException("Initialised called from non-UI thread.");
}
}
}
public void Initialize(Dispatcher dispatcher)
{
ArgumentValidator.AssertNotNull(dispatcher, "dispatcher");
lock (initializationLock)
{
this.dispatcher = dispatcher;
context = new DispatcherSynchronizationContext(dispatcher);
}
}
public void InvokeWithoutBlocking(SendOrPostCallback callback, object state)
{
ArgumentValidator.AssertNotNull(callback, "callback");
EnsureInitialized();
context.Post(callback, state);
}
public void InvokeWithoutBlocking(Action action)
{
ArgumentValidator.AssertNotNull(action, "action");
EnsureInitialized();
context.Post(state => action(), null);
}
public void InvokeAndBlockUntilCompletion(SendOrPostCallback callback, object state)
{
ArgumentValidator.AssertNotNull(callback, "callback");
EnsureInitialized();
context.Send(callback, state);
}
public void InvokeAndBlockUntilCompletion(Action action)
{
ArgumentValidator.AssertNotNull(action, "action");
EnsureInitialized();
if (dispatcher.CheckAccess())
{
action();
}
else
{
context.Send(delegate { action(); }, null);
}
}
public bool InvokeRequired
{
get
{
EnsureInitialized();
return !dispatcher.CheckAccess();
}
}
}
Events with Thread Affinity
We have seen how there are two contexts (UISynchronizationContext and ModelSynchronizationContext)
that are used to invoke delegates on the UI and model threads. Let us now turn our attention to the infrastructure which is used to give us events with thread affinity.
Figure: ViewModelBase class signals property changes via the PropertyChangeNotifier
DelegateManager Class
In order to invoke a delegate on the same thread that the event was subscribed to, we make use of a DelegateManager.
The DelegateManager class allows us to invoke a list of delegates, where each delegate can be associated with a particular thread.
The DelegateManager also makes use of WeakReferences, which helps to ensure that memory leaks do not occur.
The DelegateManager class is provided here in its entirety:
public class DelegateManager
{
readonly bool preserveThreadAffinity;
readonly DelegateInvocationMode invocationMode;
readonly IProvider<ISynchronizationContext> contextProvider;
readonly bool useWeakReferences = true;
readonly List<DelegateReference> delegateReferences = new List<DelegateReference>();
readonly object membersLock = new object();
readonly Dictionary<DelegateReference, ISynchronizationContext> synchronizationContexts
= new Dictionary<DelegateReference, ISynchronizationContext>();
</span> /// of the <span class="code-SummaryComment"><see cref="DelegateManager"/> class.</summary>
</span> /// <span class="code-SummaryComment"><param name="preserveThreadAffinity">If set to <c>true</c>,
</span> /// delegate invocation will occur using the <span class="code-SummaryComment"><see cref="ISynchronizationContext"/>
</span> /// provided by the specified context provider.<span class="code-SummaryComment"></param>
</span> /// <span class="code-SummaryComment"><param name="useWeakReferences">If <c>true</c> weak references will be used.</param>
</span> /// <span class="code-SummaryComment"><param name="invocationMode">The invocation mode.
</span> /// If <span class="code-SummaryComment"><c>Blocking</c> delegates will be invoked
</span> /// in serial, other in parallel.<span class="code-SummaryComment"></param>
</span> /// <span class="code-SummaryComment"><param name="contextProvider">The context provider,
</span> /// which is used to supply a context when a delegate is added.
/// If preservedThreadAffinity is <span class="code-SummaryComment"><c>false</c>, this value will be ignored.</param>
</span> public DelegateManager(bool preserveThreadAffinity = false,
bool useWeakReferences = false,
DelegateInvocationMode invocationMode = DelegateInvocationMode.Blocking,
IProvider<ISynchronizationContext> contextProvider = null)
{
this.preserveThreadAffinity = preserveThreadAffinity;
this.invocationMode = invocationMode;
this.contextProvider = contextProvider;
this.useWeakReferences = useWeakReferences;
if (contextProvider == null)
{
this.contextProvider = new SynchronizationContextProvider();
}
}
/// <span class="code-SummaryComment"><summary>
</span> /// Adds the specified target delegate to the list of delegates
/// that are invoked when <span class="code-SummaryComment"><see cref="InvokeDelegates"/> is called.
</span> /// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="targetDelegate">The target delegate.</param>
</span> public void Add(Delegate targetDelegate)
{
ArgumentValidator.AssertNotNull(targetDelegate, "targetDelegate");
var reference = new DelegateReference(targetDelegate, useWeakReferences);
lock (membersLock)
{
delegateReferences.Add(reference);
if (preserveThreadAffinity)
{
synchronizationContexts[reference] = contextProvider.ProvidedItem;
}
}
}
/// <span class="code-SummaryComment"><summary>
</span> /// Removes the specified target delegate from the list of delegates.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="targetDelegate">The target delegate.</param>
</span> public void Remove(Delegate targetDelegate)
{
lock (membersLock)
{
var removedItems = delegateReferences.RemoveAll(
reference =>
{
Delegate target = reference.Delegate;
return target == null || targetDelegate.Equals(target);
});
if (preserveThreadAffinity)
{
foreach (var delegateReference in removedItems)
{
synchronizationContexts.Remove(delegateReference);
}
}
}
}
/// <span class="code-SummaryComment"><summary>
</span> /// Invokes each delegate.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="args">The args included during delegate invocation.</param>
</span> /// <span class="code-SummaryComment"><exception cref="Exception">
</span> /// Rethrown exception if a delegate invocation raises an exception.
/// <span class="code-SummaryComment"></exception>
</span> public void InvokeDelegates(params object[] args)
{
IEnumerable<DelegateReference> delegates;
/* Retrieve the valid delegates by first trim
* the collection of null delegates. */
lock (membersLock)
{
var removedItems = delegateReferences.RemoveAll(
listener => listener.Delegate == null);
if (preserveThreadAffinity)
{
/* Clean the synchronizationContexts of those removed
* in the preceding step. */
foreach (var delegateReference in removedItems)
{
synchronizationContexts.Remove(delegateReference);
}
}
/* The lock prevents changes to the collection,
* therefore we can safely compile our list. */
delegates = (from reference in delegateReferences
select reference).ToList();
}
/* At this point any changes to the delegateReferences collection
* won't be noticed. */
foreach (var reference in delegates)
{
if (!preserveThreadAffinity)
{
reference.Delegate.DynamicInvoke(args);
continue;
}
var context = synchronizationContexts[reference];
DelegateReference referenceInsideCloser = reference;
Exception exception = null;
var callback = new SendOrPostCallback(
delegate
{
try
{
referenceInsideCloser.Delegate.DynamicInvoke(args);
}
catch (Exception ex)
{
exception = ex;
}
});
switch (invocationMode)
{
case DelegateInvocationMode.Blocking:
context.InvokeAndBlockUntilCompletion(callback, null);
break;
case DelegateInvocationMode.NonBlocking:
context.InvokeWithoutBlocking(callback, null);
break;
default:
throw new ArgumentOutOfRangeException("Unknown DispatchMode: "
+ invocationMode.ToString("G"));
}
/* Rethrowing the exception may be missed
* in a DispatchMode.Post scenario. */
if (exception != null)
{
throw exception;
}
}
}
}
SynchronizationContextProvider Class
So how do we invoke a delegate on a particular thread? Well, this can't be done arbitrarily.
For that we make use of an extensibility point which I use throughout the proof of concept. It is an IProvider<ISynchronizationContext>
whose default implementation is the SynchronizationContextProvider.
It determines the ISynchronizationContext that is used to associate with a delegate. Notice above, how it is passed to the DelegateManager's constructor.
</span>/// The default implementation for an <span class="code-SummaryComment"><see cref="IProvider{T}"/>
</span>/// providing an <span class="code-SummaryComment"><see cref="ISynchronizationContext"/> instance.
</span>/// <span class="code-SummaryComment"></summary>
</span>public class SynchronizationContextProvider : IProvider<ISynchronizationContext>
{
public ISynchronizationContext ProvidedItem
{
get
{
if (Deployment.Current.Dispatcher.CheckAccess())
{
return UISynchronizationContext.Instance;
}
return ModelSynchronizationContext.Instance;
}
}
}
PropertyChangeNotifier Class
The PropertyChangeNotifier makes use of two DelegateManagers. One for the INotifyPropertyChanged event,
and the other for the INotifyPropertyChanging event. This class uses a WeakReference to associate itself with a host class,
in order to take over the responsibilities of property change notification. It also adds some niceties like cancellable changes.
My favourite method from this class is the Assign method. I use it everywhere for property changes, because it
- takes care of notifying that the property is about to be changed,
- performs the changes (unless it was cancelled),
- and then notifies that the change has been performed.
Several examples of its use can be found in the MainPageViewModel class. The following excerpt shows one such example:
string message;
public string Message
{
get
{
return message;
}
set
{
Assign(Meta.Message, ref message, value);
}
}
The Assign method takes the name of the property, in this case it is a generated name
from the T4 Metadata Generation template,
a reference to the field that may be changed, and the new value.
Returning to the actual implementation of the PropertyChangeNotifier, here it is provided in full:
</span>/// This class provides an implementation of the <span class="code-SummaryComment"><see cref="INotifyPropertyChanged"/>
</span>/// and <span class="code-SummaryComment"><see cref="INotifyPropertyChanging"/> interfaces.
</span>/// Extended <span class="code-SummaryComment"><see cref="PropertyChangedEventArgs"/> and <see cref="PropertyChangingEventArgs"/>
</span>/// are used to provides the old value and new value for the property.
/// <span class="code-SummaryComment"><seealso cref="PropertyChangedEventArgs{TProperty}"/>
</span>/// <span class="code-SummaryComment"><seealso cref="PropertyChangingEventArgs{TProperty}"/>
</span>/// <span class="code-SummaryComment"></summary>
</span>[Serializable]
public sealed class PropertyChangeNotifier : INotifyPropertyChanged, INotifyPropertyChanging
{
readonly WeakReference ownerWeakReference;
readonly DelegateManager changedEventManager;
readonly DelegateManager changingEventManager;
/// <span class="code-SummaryComment"><summary>
</span> /// Gets the owner for testing purposes.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><value>The owner.</value>
</span> internal object Owner
{
get
{
if (ownerWeakReference.Target != null)
{
return ownerWeakReference.Target;
}
return null;
}
}
/// <span class="code-SummaryComment"><summary>
</span> /// Initializes a new instance
/// of the <span class="code-SummaryComment"><see cref="PropertyChangeNotifier"/> class.
</span> /// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="owner">The intended sender
</span> /// of the <span class="code-SummaryComment"><code>PropertyChanged</code> event.</param>
</span> public PropertyChangeNotifier(object owner)
: this(owner, true)
{
/* Intentionally left blank. */
}
/// <span class="code-SummaryComment"><summary>
</span> /// Initializes a new instance
/// of the <span class="code-SummaryComment"><see cref="PropertyChangeNotifier"/> class.
</span> /// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="owner">The intended sender
</span> /// <span class="code-SummaryComment"><param name="useExtendedEventArgs">If <c>true</c> the
</span> /// generic <span class="code-SummaryComment"><see cref="PropertyChangedEventArgs{TProperty}"/>
</span> /// and <span class="code-SummaryComment"><see cref="PropertyChangingEventArgs{TProperty}"/>
</span> /// are used when raising events.
/// Otherwise, the non-generic types are used, and they are cached
/// to decrease heap fragmentation.<span class="code-SummaryComment"></param>
</span> /// of the <span class="code-SummaryComment"><code>PropertyChanged</code> event.</param>
</span> public PropertyChangeNotifier(object owner, bool useExtendedEventArgs)
: this(owner, useExtendedEventArgs, true)
{
/* Intentionally left blank. */
}
/// <span class="code-SummaryComment"><summary>
</span> /// Initializes a new instance
/// of the <span class="code-SummaryComment"><see cref="PropertyChangeNotifier"/> class.
</span> /// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="owner">The intended sender
</span> /// <span class="code-SummaryComment"><param name="useExtendedEventArgs">If <c>true</c> the
</span> /// generic <span class="code-SummaryComment"><see cref="PropertyChangedEventArgs{TProperty}"/>
</span> /// and <span class="code-SummaryComment"><see cref="PropertyChangingEventArgs{TProperty}"/>
</span> /// are used when raising events.
/// Otherwise, the non-generic types are used, and they are cached
/// to decrease heap fragmentation.<span class="code-SummaryComment"></param>
</span> /// of the <span class="code-SummaryComment"><code>PropertyChanged</code> event.</param>
</span> /// <span class="code-SummaryComment"><param name="useExtendedEventArgs">If <c>true</c> the
</span> /// generic <span class="code-SummaryComment"><see cref="PropertyChangedEventArgs{TProperty}"/>
</span> /// and <span class="code-SummaryComment"><see cref="PropertyChangingEventArgs{TProperty}"/>
</span> /// are used when raising events. Otherwise, the non-generic types
/// are used, and they are cached
/// to decrease heap fragmentation.<span class="code-SummaryComment"></param>
</span> /// <span class="code-SummaryComment"><param name="preserveThreadAffinity">Indicates whether to invoke handlers
</span> /// on the thread that the subscription took place.<span class="code-SummaryComment"></param>
</span> public PropertyChangeNotifier(object owner, bool useExtendedEventArgs, bool preserveThreadAffinity)
{
ArgumentValidator.AssertNotNull(owner, "owner");
ownerWeakReference = new WeakReference(owner);
this.useExtendedEventArgs = useExtendedEventArgs;
changedEventManager = new DelegateManager(preserveThreadAffinity);
changingEventManager = new DelegateManager(preserveThreadAffinity);
}
#region event PropertyChanged
/// <span class="code-SummaryComment"><summary>
</span> /// Occurs when a property value changes.
/// <span class="code-SummaryComment"></summary>
</span> public event PropertyChangedEventHandler PropertyChanged
{
add
{
if (OwnerDisposed)
{
return;
}
changedEventManager.Add(value);
}
remove
{
if (OwnerDisposed)
{
return;
}
changedEventManager.Remove(value);
}
}
#region Experimental Thread Affinity
public bool MaintainThreadAffinity { get; set; }
#endregion
/// <span class="code-SummaryComment"><summary>
</span> /// Raises the <span class="code-SummaryComment"><see cref="E:PropertyChanged"/> event.
</span> /// If the owner has been GC'd then the event will not be raised.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="e">The <see cref="System.ComponentModel.PropertyChangedEventArgs"/>
</span> /// instance containing the event data.<span class="code-SummaryComment"></param>
</span> void OnPropertyChanged(PropertyChangedEventArgs e)
{
changedEventManager.InvokeDelegates(Owner, e);
}
#endregion
/// <span class="code-SummaryComment"><summary>
</span> /// Assigns the specified newValue to the specified property
/// and then notifies listeners that the property has changed.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><typeparam name="TProperty">The type of the property.</typeparam>
</span> /// <span class="code-SummaryComment"><param name="propertyName">Name of the property. Can not be null.</param>
</span> /// <span class="code-SummaryComment"><param name="property">A reference to the property that is to be assigned.</param>
</span> /// <span class="code-SummaryComment"><param name="newValue">The value to assign the property.</param>
</span> /// <span class="code-SummaryComment"><exception cref="ArgumentNullException">
</span> /// Occurs if the specified propertyName is <span class="code-SummaryComment"><code>null</code>.</exception>
</span> /// <span class="code-SummaryComment"><exception cref="ArgumentException">
</span> /// Occurs if the specified propertyName is an empty string.<span class="code-SummaryComment"></exception>
</span> public PropertyAssignmentResult Assign<TProperty>(
string propertyName, ref TProperty property, TProperty newValue)
{
if (OwnerDisposed)
{
return PropertyAssignmentResult.OwnerDisposed;
}
ArgumentValidator.AssertNotNullOrEmpty(propertyName, "propertyName");
ValidatePropertyName(propertyName);
return AssignWithNotification(propertyName, ref property, newValue);
}
/// <span class="code-SummaryComment"><summary>
</span> /// Slow. Not recommended.
/// Assigns the specified newValue to the specified property
/// and then notifies listeners that the property has changed.
/// Assignment nor notification will occur if the specified
/// property and newValue are equal.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><typeparam name="T"></typeparam>
</span> /// <span class="code-SummaryComment"><typeparam name="TProperty">The type of the property.</typeparam>
</span> /// <span class="code-SummaryComment"><param name="expression">The expression that is used to derive the property name.
</span> /// Should not be <span class="code-SummaryComment"><code>null</code>.</param>
</span> /// <span class="code-SummaryComment"><param name="property">A reference to the property that is to be assigned.</param>
</span> /// <span class="code-SummaryComment"><param name="newValue">The value to assign the property.</param>
</span> /// <span class="code-SummaryComment"><exception cref="ArgumentNullException">
</span> /// Occurs if the specified propertyName is <span class="code-SummaryComment"><code>null</code>.</exception>
</span> /// <span class="code-SummaryComment"><exception cref="ArgumentException">
</span> /// Occurs if the specified propertyName is an empty string.<span class="code-SummaryComment"></exception>
</span> public PropertyAssignmentResult Assign<T, TProperty>(
Expression<Func<T, TProperty>>
As you will notice, there is also the facility to use lambda expressions for property names, which I wouldn't recommend for poor performance reasons.
So we see that the PropertyChangeNotifier makes use of DelegateManagers to aggregate delegates,
and invoke them when the PropertyChanged or PropertyChanging events are raised.
In order to avoid duplication, I sometimes make use of the NotifyPropertyChangeBase class.
NotifyPropertyChangeBase Class
The NotifyPropertyChangeBase class encapsulates a PropertyChangeNotifier instance, that goes some way to enabling serialization
of the PropertyChangeNotifier, and lazy loading. It also provides for a little terser code, in that field qualification can be omitted.
</span>/// A base class for property change notification.
/// <span class="code-SummaryComment"><seealso cref="PropertyChangeNotifier"/>.
</span>/// <span class="code-SummaryComment"></summary>
</span>[Serializable]
public abstract class NotifyPropertyChangeBase : INotifyPropertyChanged, INotifyPropertyChanging
{
[field: NonSerialized]
PropertyChangeNotifier notifier;
[field: NonSerialized]
object notifierLock;
/// <span class="code-SummaryComment"><summary>
</span> /// Gets the PropertyChangeNotifier. It is lazy loaded.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><value>The PropertyChangeNotifier.</value>
</span> protected PropertyChangeNotifier Notifier
{
get
{
/* It is cheaper to create an object to lock, than to instantiate
* the PropertyChangeNotifier, because hooking up the events
* for many instances is expensive. */
if (notifier == null)
{
lock (notifierLock)
{
if (notifier == null)
{
notifier = new PropertyChangeNotifier(this);
}
}
}
return notifier;
}
}
[OnDeserializing]
internal void OnDeserializing(StreamingContext context)
{
Initialize();
}
/// <span class="code-SummaryComment"><summary>
</span> /// Assigns the specified newValue to the specified property
/// and then notifies listeners that the property has changed.
/// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><typeparam name="TProperty">The type of the property.</typeparam>
</span> /// <span class="code-SummaryComment"><param name="propertyName">Name of the property. Can not be null.</param>
</span> /// <span class="code-SummaryComment"><param name="property">A reference to the property that is to be assigned.</param>
</span> /// <span class="code-SummaryComment"><param name="newValue">The value to assign the property.</param>
</span> /// <span class="code-SummaryComment"><exception cref="ArgumentNullException">
</span> /// Occurs if the specified propertyName is <span class="code-SummaryComment"><code>null</code>.</exception>
</span> /// <span class="code-SummaryComment"><exception cref="ArgumentException">
</span> /// Occurs if the specified propertyName is an empty string.<span class="code-SummaryComment"></exception>
</span> protected PropertyAssignmentResult Assign<TProperty>(
string propertyName, ref TProperty property, TProperty newValue)
{
return Notifier.Assign(propertyName, ref property, newValue);
}
/// <span class="code-SummaryComment"><summary>
</span> /// When deserialization occurs fields are not instantiated,
/// therefore we must instantiate the notifier.
/// <span class="code-SummaryComment"></summary>
</span> void Initialize()
{
notifierLock = new object();
}
public NotifyPropertyChangeBase()
{
Initialize();
}
#region Property change notification
/// <span class="code-SummaryComment"><summary>
</span> /// Occurs when a property value changes.
/// <span class="code-SummaryComment"><seealso cref="PropertyChangeNotifier"/>
</span> /// <span class="code-SummaryComment"></summary>
</span> public event PropertyChangedEventHandler PropertyChanged
{
add
{
Notifier.PropertyChanged += value;
}
remove
{
Notifier.PropertyChanged -= value;
}
}
/// <span class="code-SummaryComment"><summary>
</span> /// Occurs when a property value is changing.
/// <span class="code-SummaryComment"><seealso cref="PropertyChangeNotifier"/>
</span> /// <span class="code-SummaryComment"></summary>
</span> public event PropertyChangingEventHandler PropertyChanging
{
add
{
Notifier.PropertyChanging += value;
}
remove
{
Notifier.PropertyChanging -= value;
}
}
#endregion
}
This class serves as the base class for our ViewModelBase class.
ViewModelBase Class
This class is an abstract class that is the base class for all, well, view models. In the proof of concept it has virtually no implementation,
and serves merely as a placeholder for now.
public abstract class ViewModelBase : NotifyPropertyChangeBase
{
protected ViewModelBase()
{
Notifier.MaintainThreadAffinity = true;
}
}
By specifying that our PropertyChangeNotifier maintains thread affinity, it means that event handlers will be executed on the thread
of subscription (either the UI thread or the model thread).
A Collection with Event Thread Affinity
ObservableCollections are frequently used in WPF and Silverlight applications to enable automatic UI updates when items are added to,
or removed from, a collection. Earlier in this article, we looked at the sample application's use of a custom collection in the MainPageViewModel.
This collection was a SynchronizedObservableCollection, which happens to make use of our DelegateManager class in order to associate
the thread on which an event is subscribed, and the handler. This means that when an item is added or removed from the collection,
each NotifyCollectionChangedEventHandler subscriber is notified on the correct thread.
This is important, because UI elements that are data bound to the collection will raise an exception if the handler is not invoked on the UI thread.
If we did not have this mechanism then we would need to manually invoke any updates to the collection on the UI thread.
SynchronizedObservableCollection Class
The SynchronizedObservableCollection looks much like the ObservableCollection implementation in the FCL,
but with some notable differences. It makes use of the DelegateManager, which allows for the INotifyCollectionChanged
event handlers to be invoked on the correct threads. In order to help prevent race conditions,
changes to the collection are invoked on the UI thread using the UISynchronizationContext.
</span>/// Provides <span class="code-SummaryComment"><see cref="INotifyCollectionChanged"/> events on the subscription thread
</span>/// using an <span class="code-SummaryComment"><see cref="ISynchronizationContext"/>.
</span>/// <span class="code-SummaryComment"></summary>
</span>/// <span class="code-SummaryComment"><typeparam name="T">The type of items in the collection.</typeparam>
</span>public class SynchronizedObservableCollection<T> : Collection<T>,
INotifyCollectionChanged, INotifyPropertyChanged
{
bool busy;
readonly DelegateManager collectionChangedManager;
readonly ISynchronizationContext uiContext;
/// <span class="code-SummaryComment"><summary>
</span> /// Occurs when the items list of the collection has changed,
/// or the collection is reset.
/// <span class="code-SummaryComment"></summary>
</span> public event NotifyCollectionChangedEventHandler CollectionChanged
{
add
{
collectionChangedManager.Add(value);
}
remove
{
collectionChangedManager.Remove(value);
}
}
PropertyChangedEventHandler propertyChanged;
/// <span class="code-SummaryComment"><summary>
</span> /// Occurs when a property value changes.
/// <span class="code-SummaryComment"></summary>
</span> event PropertyChangedEventHandler INotifyPropertyChanged.PropertyChanged
{
add
{
propertyChanged += value;
}
remove
{
propertyChanged -= value;
}
}
/// <span class="code-SummaryComment"><summary>
</span> /// Initializes a new instance
/// of the <span class="code-SummaryComment"><see cref="SynchronizedObservableCollection<T>"/> class.
</span> /// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="contextProvider">The synchronization context provider,
</span> /// which is used to determine on what thread a handler is invoked.<span class="code-SummaryComment"></param>
</span> public SynchronizedObservableCollection(
IProvider<ISynchronizationContext> contextProvider = null)
{
uiContext = UISynchronizationContext.Instance;
collectionChangedManager = new DelegateManager(true, contextProvider: contextProvider);
}
/// <span class="code-SummaryComment"><summary>
</span> /// Initializes a new instance
/// of the <span class="code-SummaryComment"><see cref="SynchronizedObservableCollection<T>"/> class.
</span> /// <span class="code-SummaryComment"></summary>
</span> /// <span class="code-SummaryComment"><param name="collection">The collection to copy.</param>
</span> /// <span class="code-SummaryComment"><param name="contextProvider">The synchronization context provider,
</span> /// which is used to determine on what thread a handler is invoked.<span class="code-SummaryComment"></param>
</span> public SynchronizedObservableCollection(IEnumerable<T> collection,
IProvider<ISynchronizationContext> contextProvider = null) : this(contextProvider)
{
ArgumentValidator.AssertNotNull(collection, "collection");
CopyFrom(collection);
}
public SynchronizedObservableCollection(List<T> list,
IProvider<ISynchronizationContext> contextProvider = null)
: base(list != null ? new List<T>(list.Count) : list)
{
uiContext = UISynchronizationContext.Instance;
collectionChangedManager = new DelegateManager(true, contextProvider: contextProvider);
CopyFrom(list);
}
void PreventReentrancy()
{
if (busy)
{
throw new InvalidOperationException(
"Cannot Change SynchronizedObservableCollection");
}
}
protected override void ClearItems()
{
uiContext.InvokeAndBlockUntilCompletion(
delegate
{
PreventReentrancy();
base.ClearItems();
OnPropertyChanged("Count");
OnPropertyChanged("Item[]");
OnCollectionChanged(new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Reset));
});
}
void CopyFrom(IEnumerable<T> collection)
{
uiContext.InvokeAndBlockUntilCompletion(
delegate
{
IList<T> items = Items;
if (collection != null && items != null)
{
using (IEnumerator<T> enumerator = collection.GetEnumerator())
{
while (enumerator.MoveNext())
{
items.Add(enumerator.Current);
}
}
}
});
}
protected override void InsertItem(int index, T item)
{
uiContext.InvokeAndBlockUntilCompletion(
delegate
{
base.InsertItem(index, item);
OnPropertyChanged("Count");
OnPropertyChanged("Item[]");
OnCollectionChanged(new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Add, item, index));
});
}
protected virtual void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
{
busy = true;
try
{
collectionChangedManager.InvokeDelegates(null, e);
}
finally
{
busy = false;
}
}
protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
{
if (propertyChanged != null)
{
busy = true;
try
{
propertyChanged(this, e);
}
finally
{
busy = false;
}
}
}
void OnPropertyChanged(string propertyName)
{
OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
}
protected override void RemoveItem(int index)
{
uiContext.InvokeAndBlockUntilCompletion(
delegate
{
PreventReentrancy();
T changedItem = base[index];
base.RemoveItem(index);
OnPropertyChanged("Count");
OnPropertyChanged("Item[]");
OnCollectionChanged(new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Remove, changedItem, index));
});
}
protected override void SetItem(int index, T item)
{
uiContext.InvokeAndBlockUntilCompletion(
delegate
{
PreventReentrancy();
T oldItem = base[index];
base.SetItem(index, item);
OnPropertyChanged("Item[]");
OnCollectionChanged(new NotifyCollectionChangedEventArgs(
NotifyCollectionChangedAction.Replace, item, oldItem, index));
});
}
}
Infrastructure Unit Tests
Curiously, the infrastructure that gives us the ability to unit test Silverlight applications does not come with the Silverlight Tools (SDK),
but with the Silverlight Toolkit.
I created some tests during development of the proof of concept. This proved to be very useful during its development,
as it allowed me to debug and identify threads, without relying on the UI.
Figure: Silverlight Unit Testing
The unit testing infrastructure within Visual Studio is not Silverlight Unit Test aware. This means that executing a unit test requires setting
the default page of your application, to the generated unit test page. In the case of the sample application, this is the Tests.aspx page.
Figure: Tests completed.
The following listing shows the content of the threading tests:
[TestClass]
public class ViewModelBaseTests : SilverlightTest
{
[TestMethod]
public void ViewModelShouldRaisePropertyChangedOnSameThread()
{
var autoResetEvent = new AutoResetEvent(false);
bool raised = false;
var mockViewModel = new MockViewModel();
mockViewModel.PropertyChanged +=
delegate
{
raised = true;
autoResetEvent.Set();
};
mockViewModel.StringMember = "Test";
autoResetEvent.WaitOne();
Assert.IsTrue(raised);
}
[TestMethod]
public void ViewModelShouldRaisePropertyChangedOnSubscriptionThread()
{
var mockViewModel = new MockViewModel();
var autoResetEvent = new AutoResetEvent(false);
bool raised = false;
Thread subscriberThread = null;
Thread raisedOnThread = null;
ThreadPool.QueueUserWorkItem(
delegate
{
AutoResetEvent innerResetEvent = new AutoResetEvent(false);
ModelSynchronizationContext.Instance.InvokeWithoutBlocking(
delegate
{
mockViewModel.PropertyChanged +=
delegate
{
raised = true;
raisedOnThread = Thread.CurrentThread;
autoResetEvent.Set();
};
innerResetEvent.Set();
});
Assert.IsTrue(innerResetEvent.WaitOne(30000), "timed out.");
Thread threadToSetProperty = new Thread(
delegate()
{
Assert.AreNotEqual(subscriberThread, Thread.CurrentThread);
mockViewModel.StringMember = "Test";
});
threadToSetProperty.Start();
});
subscriberThread = ModelSynchronizationContext.Instance.Thread;
autoResetEvent.WaitOne();
Assert.IsTrue(raised);
Assert.AreEqual(subscriberThread.ManagedThreadId, raisedOnThread.ManagedThreadId);
}
}
Notice that the test itself derives from Microsoft.Silverlight.Testing.SilverlightTest,
which differs from run-of-the-mill Desktop CLR unit tests that use the Microsoft unit testing tools.
Deriving from SilverlightTest affords the ability to perform asynchronous tests, but that is outside of the scope of this article.
Conclusion
In this article we have seen how the Model Thread View Thread pattern uses the same facilities as the MVVM pattern, to better separate the execution of view control specific logic from the rest of the application. This provides us with greater assurance of UI responsiveness, and in the case of Silverlight, facilitates such things as synchronous WCF communication. It also reduces the need for UI thread invocation, and helps to increase model scalability; allowing for event handler logic to grow without degrading UI responsiveness.
This article serves as a definition of the pattern for peer review, and also as proof of concept for the infrastructure required to support the pattern.
I hope you find this project useful. If so, then I'd appreciate it if you would rate it and/or leave feedback below. This will help me to make my next article better.
History
April 2010
Submit an article or tip
Post your Blog
News 
Suggestion 
Bug 
Joke 
Rant 
Admin 
