Flippant Remarks about MVVM

Read this Josh Smith article at MSDN : “WPF Apps With The Model-View-ViewModel Design Pattern”; it is both technical and places the technology in a historical context. This article also freely refers to other articles (not necessarily from MSDN).

In order to implement MVVM (by hand), you have to know the innards of WPF. You have to know the technical “issues” throughout WPF. I assume that solutions like the MVVM Light Toolkit exist to reduce the amount of intimate knowledge of WPF required to implement MVVM. (By the way, I assume that the MVVM Light Toolkit is different from the WPF Model-View-ViewModel Toolkit.)

The word ‘innards’ implies that:

• You are familiar with the concept of WPF data binding. Memorizing data binding syntax is truly impressive but there is a cheat sheet. In the MVVM context, the declarative style of XAML-based data binding reminds me of XPath assertions—so these can be called binding assertions against the Data Context.
• You are familiar with WPF data templates.
• You understand what “commanding” is in WPF. The Bryan Noyes article, “Advanced WPF: Understanding Routed Events and Commands in WPF,” helps.
• You ask, “What happened to the x:Name elements?” When your XAML is almost completely devoid of x:Name elements, you know you are using MVVM correctly. This is a marked difference between MVVM WPF design and id-based HTML/CSS/JavaScript design.
• You understand some of the technology/history surrounding INotifyPropertyChanged and Depend``e``ncyPropert``y. This is a prime example of the complications here (some relevant links below).### WPF/MVVM Resources

  “[WPF Apps With The Model-View-ViewModel Design Pattern](http://msdn.microsoft.com/en-us/magazine/dd419663.aspx)”	This Josh Smith MSDN article is the heart of the matter.
  “[WPF MVVM Video by Jason Dolinger](http://hugeonion.com/2009/03/08/wpf-mvvm-video-by-jason-dolinger/)”	“Here is a direct link to the video: http://www.lab49.com/files/videos/Jason%20Dolinger%20MVVM.wmv And here’s a link to a blog post about it with a link to the source code: http://blog.lab49.com/archives/2650 …”
  “[Advanced WPF: Understanding Routed Events and Commands in WPF](http://msdn.microsoft.com/magazine/cc785480)”	“In this article I am going to focus on two very important items in the list of new WPF elements to master. These items—routed events and routed commands—are related to each other. They form the basis for communication among the various parts of your user interface—whether those parts are individual controls on one big Window class or whether they are controls and their supporting code in separate, decoupled parts of your user interface. For this article I am assuming you are already familiar with the fundamentals of WPF, such as how to construct a UI using built-in WPF controls and declaring the layout of your UI in XAML.”
  “[INotifyPropertyChanged vs. DependencyProperty in ViewModel](http://stackoverflow.com/questions/291518/inotifypropertychanged-vs-dependencyproperty-in-viewmodel)”	“The choice is totally based on your business logic and UI abstraction level. If you don’t want a good separation then DP will work for you. `Depend``e``ncyPropert``y` will be applicable mainly at the `VisualElements` level so it won’t be good idea if we create lot of DPs for each of our business requirements. And there is a big cost for DP than a `INotifyPropertyChanged`. When you design a WPF/Silverlight try to design UI and `ViewModel` totally separate so that at any point of time we can change the Layout and UI controls…”
  “[Interesting thread on data binding](http://joshsmithonwpf.wordpress.com/2007/05/30/interesting-thread-on-data-binding/)”	“Yesterday I started a thread on the WPF Forum which has turned out to be rather interesting. I won’t go into too much detail about it in this post, but here’s the general gist. Normally the WPF data binding system requires a data object to send out notifications when one of its properties has changed so that the new value can be displayed in the UI. There are three ways to do this: 1. Raise a `PropertyNameChanged` event when a property has been changed (ex. Raise a `NameChanged` event when the Name property of an object is set). 2. Implement `INotifyPropertyChanged` on the data object and raise its PropertyChanged event when a property is set to a new value. 3. Derive the business object’s class from `DependencyObject` and implement the property as a dependency property. DPs handle all of the change notification work for you.”
  “[A base class which implements INotifyPropertyChanged](http://joshsmithonwpf.wordpress.com/2007/08/29/a-base-class-which-implements-inotifypropertychanged/)”	“The longer I’ve worked with WPF, the more implementations I have seen of the `INotifyPropertyChanged` interface. It’s everywhere. I have seen dozens upon dozens of classes all implement the interface separately, even though most of those classes descend directly from `Object`. This blog post examines the virtues of creating a base class which implements that interface, and deriving as many classes as possible from it. Consolidating your implementation of `INotifyPropertyChanged` into a base class has several benefits.”
  “[Overview of dependency properties in WPF](http://joshsmithonwpf.wordpress.com/2007/06/22/overview-of-dependency-properties-in-wpf/)”	“WPF leverages a property system which allows for much more sophisticated and intelligent usage of properties than was possible before. In addition to using regular CLR properties, the Windows Presentation Foundation also uses dependency properties. Dependency properties are used when the resolution of a property’s value is based on other properties or runtime settings (such as operating system settings).”
  “[One way to avoid messy PropertyChanged event handling](http://joshsmithonwpf.wordpress.com/2009/07/11/one-way-to-avoid-messy-propertychanged-event-handling/)”	“When working with objects that implement `INotifyPropertyChanged`, as most `ViewModel` objects tend to do, it often becomes necessary to attach a handler to their `PropertyChanged` event. Your code can quickly accumulate many event handling methods full of conditional statements that check if `e.PropertyName` equals some hard-coded string value. This leads to messy, brittle code that becomes difficult to maintain as the mess gets larger.”
  “[Is there a better way to update UI Element with Dispatcher?](http://stackoverflow.com/questions/1148029/is-there-a-better-way-to-update-ui-element-with-dispatcher)”	“The `Dispatcher.Invoke` is a good way of updating your UI. UI actions have to be performed by the UI Thread, the Dispatcher takes care of this.” “You can make your code a bit shorter by using Lambda expressions:” “…Dispatcher.Invoke((Action<string>) ((data) => { label1.Content = data; })); …”
  “[Lambda Expressions + Dispatcher.BeginInvoke() in C# = syntax I always forget](http://www.chordfusion.com/blog/post/2009/07/21/Lambda-Expressions-2b-DispatcherBeginInvoke()-in-C-3d-syntax-I-always-forget.aspx)”	“I love C#. I love WPF. I love lambda expressions. I love `Dispatcher.BeginInvoke()`. With all of that love, how is it that I always forget the correct syntax for using `Dispatcher.BeginInvoke()` with a lambda expression? I don’t know, but it drives me crazy that I do. That’s why today’s Thought of the Day is simply this: the syntax for using `Dispatcher.BeginInvoke()` with a lambda expression.” …this.Dispatcher.BeginInvoke(DispatcherPriority.Normal, new ThreadStart(() => { // Do something awesome here on the UI thread. }));
  “[Windows Presentation Foundation Data Binding: Part 1](http://msdn.microsoft.com/en-us/library/aa480224.aspx)”	This 2006, Shawn Wildermuth article maybe out of date in areas (maybe) but serves as great historical context.

  rasx()