This is a copy-and-paste from an email to a friend, but has a few observations worth sharing publicly
A couple discussions on knockout.js, angular.js and backbone.js:
http://stackoverflow.com/questions/5112899/knockout-js-vs-backbone-js?rq=1
Previously, I didn’t pay much attention to any of these. But am changing my tune. Why? I finally found a way to use the MVVM pattern that really makes sense and plan to follow that when it makes sense with web programming too. Props to Microsoft evangelist Jerry Nixon for his walkthrough video: http://blog.jerrynixon.com/2012/08/most-people-are-doing-mvvm-all-wrong.html, which in particular had some binding tips for Visual Studio I didn’t even know existed and a nice DelegateCommand class.
My initial experience with MVVM was miserable. For one thing, it is incorrectly named…should be MVMV (as in Model – View Model – View). But then, so is MVC, which should be Model – Controller – View. Because in both cases, the View Model or Controller is the code that sits between a UI View and the task-related code, e.g. a method that grabs a bunch of image URLs based on a search term. The MVVM framework I chose to use was complicated and couldn’t handle everything. Lots of hacks went into Ballistica. So, ironically, the promise of better maintainability was so broken that I’ve never found the time to update the app.
I also found that there is a lot of strict adherence to one model per view model. Really a model is just a class file. So if, for example, you need one class that handles status messages and another that build outlines there’s no reason why a single View Model can’t talk to them both. Now that I have that straight and have learned how to use my IDE more effectively, it has made much more sense. My current project has 111 lines of XAML in the main Window (including whitespace), but just 12 lines in its code-behind C# file (including whitespace and curly brackets)…and all it does is launch the window:
using System.Windows;
namespace HorizontalBuilder2
{
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
}
}
All the controlling logic resides either in the View Model class file or in the model classes.
Here’s an example of XAML that helps explain why Microsoft saw fit to not use SVG:
<MenuItem Command="{Binding BuildOutlinesCommand, Mode=OneWay}" Header="_Build Outlines" InputGestureText="CTRL+B" IsEnabled="{Binding Done, Mode=OneWay}">
<MenuItem.Icon>
<icons:IconGeom />
</MenuItem.Icon>
</MenuItem>
First of all, they could create things like application menus. Then bind various attributes to logical code. In this example, for instance, selecting “Build Outlines” from the menu triggers the BuildOutlinesCommand method. The underscore in front of the Header text allows the user to use ALT-key shortcuts, although I’ve never enjoyed that bit of Windows UI. It’s always just seemed easier to remember something like CTRL-B, which cuts out at least one step, so that’s included. The command is enabled depending on various states of the application. While you can name an item and refer to it in code, e.g. myMenuItem.Enabled = true, one advantage of this way is the menu item is now just a “subscriber” to the Done value. If I had, say, another item on screen like a big “Start” button it to could just use the same snippet. The alternative would be to have to keep track in code of all the items that need to be enabled or not. Also, the programmer can look at the XAML and know where to look in code for what effects the change.
Soon I’ll be posting a nice example of an MVVM app using async Tasks with real-time UI updating…and no freezing the rest of the UI.