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:Nameelements?” When your XAML is almost completely devoid ofx:Nameelements, you know you are using MVVM correctly. This is a marked difference between MVVM WPF design andid-based HTML/CSS/JavaScript design. - You understand some of the technology/history surrounding
INotifyPropertyChangedandDependencyProperty. 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” | This Josh Smith MSDN article is the heart of the matter. |
| “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” | “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” | “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. DependencyProperty 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” | “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” | “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” | “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” | “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?” |
“The “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” |
“I love C#. I love WPF. I love lambda expressions. I love …
this.Dispatcher.BeginInvoke(DispatcherPriority.Normal, new ThreadStart(() =>
{
// Do something awesome here on the UI thread.
}));
|
| “Windows Presentation Foundation Data Binding: Part 1” | This 2006, Shawn Wildermuth article maybe out of date in areas (maybe) but serves as great historical context. |
This entry was posted on Wednesday, September 23rd, 2009 at 8:33 am and is filed under .NET related, Data Management Solutions, Digital Media Production, Expression Studio, root. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
One Response to “Flippant Remarks about MVVM”
-
the rasx() context » Blog Archive » More Flippant Remarks about MVVM Says:
November 12th, 2009 at 7:02 pm[...] last note marked a first attempt to capture MVVM. This is the second try to gain intimate understanding. I [...]