The MVVM Twilight Zone

This morning I went to one of Seattle’s numerous coffeehouses to get breakfast.  While waiting in line, the two guys in front of me (looked like coworkers) were talking, and I overheard them use the term “ViewModel.”  When their conversation came to a lull, I politely asked if they’re talking about MVVM.  The following conversation ensued, between one of the guys and myself:

Guy: “Yes, we are actually.”

Me: “Oh cool, that’s a great pattern.  Always an interesting topic.”

Guy: “We use it all the time.”

Me: “What do you like about it?”

Guy: “I like that it’s based on dependency injection.  That makes it really easy to test ViewModels.”

Me: “What do you mean that it’s based on DI?”

Guy: “I mean, it’s based on DI.  Have you ever actually used the pattern?”   [Guy2 now smirks pretentiously]

Me: “Yes, I’ve used it.  But, to me, it’s based on Models, Views, and ViewModels.  That’s it, no DI.”

Guy: “Well it sounds like you don’t really get it then.  It’s complicated, so you need to read a lot about it.”

Me: “Oh, that’s good to know.  What do you suggest I read to learn about  it?”

Guy: “Start with Josh Smith’s MVVM article in MSDN Magazine.”

I kid you not.  That is literally what the guy told me.  I burst out laughing so loud that I felt embarrassed and had to leave.  The guy must have thought I was psychotic!

It’s worth noting that my MVVM article on MSDN never once mentions dependency injection, inversion of control, or any other dependency inversion technique.  That’s because dependency inversion has nothing to do with MVVM.

Happy coding…

Using DynamicObject to intercept and marshal property changes

One of the most interesting (and potentially dangerous) new features in C# 4.0 is support for the dynamic type.  It allows certain pieces of your code to bypass the normal compile-time type checking features that we have grown to know and love.  You can use a dynamic object however you want to, and the C# compiler will ignore the members you use on it.  At runtime, if the methods/properties/etc. your code tries to use are not actually present on the object, an exception is thrown.  If they do exist, they will be linked to and invoked dynamically.   This technique is called dynamic dispatch.  What you lose in safety, you gain in flexibility.

In addition to the dynamic keyword there is also support in the .NET Framework 4.0 for creating types that support dynamic dispatch. The System.Dynamic.DynamicObject class allows you to specify how an object performs dynamic dispatch.  You can subclass DynamicObject and override some of its methods, such as TrySetMember and TryGetMember, to perform whatever logic you need to link a dynamic property set or get to a backing store.

Sound pretty cool, right?  That’s what I thought when I first heard about this functionality.  Then I thought, “Why would I ever need to use this?”  I didn’t have an answer to that question, until tonight.  It dawned on me, while trying to read something not related to programming (damn OCD!), that this could be leveraged to implement a simple, reusable means of marshaling property changes to the UI thread.

As you probably know, you cannot get or set a visual element’s properties from any thread except the thread on which it was created.  When the UI thread creates an element, that element thereafter has an affinity to the UI thread’s Dispatcher object.  The only property on an element that you can access from another thread is its Dispatcher property.  Once you have a reference to an element’s Dispatcher, you can use it to dispatch method calls that manipulate the element on the UI thread.

If you work on a lot of UI-level components and controls, like I do, you probably find yourself writing a lot of code that works with Dispatchers just to do something simple like get or set an element’s property.  What a pain!  It turns out that this pain can be somewhat eliminated by making use of DynamicObject and the dynamic keyword.  Here’s a contrived example that shows how…

The code snippet above shows how to use my DynamicElement class.  It acts as a proxy to an element, which intercepts all access to an element’s properties.  This interception allows the DynamicElement to make use of the visual element’s Dispatcher, if necessary.  Here is how the interception works for setting a property:

The TryGetMember implementation is similar to the code seen above.

You can download the source code here.  NOTE: Rename the file extension from .DOC to .ZIP and then decompress it.

Fireside chat about MVVM

Craig Shoemaker recently interviewed me for an episode of his Polymorphic Podcast. We touched on a quite few interesting topics, ranging from the merit of the code-behind file, to implementing Undo functionality, to the role of MVVM frameworks. You can check it out here:

http://weblogs.asp.net/craigshoemaker/archive/2010/05/17/advanced-mvvm-with-josh-smith.aspx