Feeds:
Posts
Comments

Archive for March, 2010

What is MVVM?

It’s a flying bat: ^^vv^^.

Sorry, I know that’s corny, but I still have to rail a bit against the name.

Anyway, Model-View-ViewModel, or MVVM for the TLA (FLAB?) loving folks, or just ViewModel for those that don’t like tongue twisters but want to pay homage to the “original” name, or Presentation Model for those Java folks, or even MVPoo for Drs. and folks fed up with the various names, is a UI design pattern. The pattern separates the display (View) from the presentation state and logic (ViewModel) and the business data and logic (Model). That’s it. Nothing more, nothing less.

So, why am I blogging about this if that’s all I have to say about what MVVM is? Because lately I’ve been reading a lot of claims about MVVM that lose track of what MVVM is, making claims that are not strictly accurate.

Let me start with one that came up in the WPF Disciples group recently. Justin Angel posted an review of Josh Smith’s Advanced MVVM book. In his review he talked about how MVVM was “essentially about these 3 things:”

1) Data Binding

2) Commands

3) VisualStateManager

See, that one rankled several folks. When MVVM was “discovered” by John Gossman, the VisualStateManager didn’t even exist. Also in those early days we had problems bending Commands to MVVM usage, as this was before RelayCommand, DelegateCommand et. al. Heck, even Data Binding isn’t an essential part, as Martin Fowler lamented about having to write boring and repetitive code to synchronize state, and even said he hoped that some day something like .NET data binding could be used. See, all of these things are implementation details, and patterns are not about implementation details. They’re about, wait for it, the pattern (see, it’s not just a clever name).

Another one that came up recently on the Disciples list was a discussion around a blog post someone had run across. This was a short post, but it generated a lot of discussion about various things. I won’t go into the details, because it was a private discussion. The blog post made two mistakes that are relevant here, though, so I’ll discuss them. The first was a similar mistake in trying to tie MVVM to implementation details like Commands and Dependency Injection. I’ve already pointed out how that’s wrong, so let’s move on to the second mistake. He stated that when following MVVM the goal was to have no code in the codebehind. This just isn’t true. Having a clean codebehind is a goal I have, since it helps with the developer/designer separation, and this goal is possible because of MVVM (and other patterns and techniques), but this isn’t a goal of MVVM. You can, and I some times do, put code in the codebehind while following a strict MVVM pattern.

Then there’s another topic that also came up in the Disciples list that’s a particular bee in my bonnet. Several folks tried to make the claim that in MVVM the ViewModel should never have a reference to the View. That’s just hogwash. Nothing in the pattern states this. What is true is that you should avoid creating a hard coupling between the ViewModel and the View, but that’s just good software architecture and has nothing at all to do with the MVVM pattern. What’s funny is these same folks have no issue with creating hard coupling between the ViewModel and the Model, which causes the exact same issues as hard coupling between the ViewModel and the View and so is just as ill advised. But there’s not a darn thing wrong with having weaker coupling, and there’s lots of reasons why you might want to have the coupling. For instance, imagine your loose coupling entailed an IView interface that exposed Show and Hide/Close methods to allow the ViewModel to control the visibility/existence of the View. Do you see anything wrong with this sort of coupling? I sure don’t. More important, do you see anything in the pattern description that discusses this? I sure don’t.

Another claim made several times by many people is that MVVM is a refinement of Presentation Model using WPF concepts like Data Binding and Commands (this argument usually being made to justify keeping the longer and more awkward name of the pattern). See, this is just a variation on the other mistakes I’ve discussed. If this statement were strictly true, then MVVM wouldn’t be a pattern, it would be a framework based on the Presentation Model pattern. Remember, patterns aren’t about how things are implemented, they are strictly about the, ahem, pattern.

Read Full Post »

The Add Reference dialog has been the biggest punching bag for Visual Studio detractors. It’s always been extremely slow and annoying, and pretty much every developer has felt the dread associated with knowing you’re going to have to add a reference to a .NET project.

So, with Visual Studio 2010, this was supposed to have been one of the areas of focus. My initial reaction was that the tweaks made here made a huge difference, and actually made the dialog usable.

Well, I have to say, my initial reaction was incredibly wrong. Yeah, the changes made a huge difference, but not for the better.

The dialog now displays nearly instantaneously. If you’re adding a reference to a project or by browsing to an assembly on disk, then the changes are going to make your heart sing. However, if you’re attempting to add a reference from the list of known assemblies, well, the old dread holds nothing to the new feeling of pure doom.

See, by loading the list asynchronously, populating the UI with every item as it’s found, they’ve actually made it take longer to load the list. Worse, because the UI is updated with every item found, it’s not really usable until the entire list is loaded. There’s nothing more frustrating than being presented with a long list of items, inviting you to scroll to locate the item you need, only to have the scroll bar jump around like a Mexican jumping bean as new items are constantly being added. This behavior is especially vexing because you don’t know when the list is finally fully loaded, and since it takes longer to load then it used to, you’re always frustrated by the jerky UI.

This is so frustrating, because this is a problem that’s really easy to solve. Loading asynchronously is the right choice… but this could be done as soon as the IDE is opened and the results cached. The list should only be populated once all of the items have been added to the cache. The user would then be able to refresh this cache if, in the corner case, there were some change to the actual assemblies that would be available. Problem solved. The user will rarely have to wait for this stupid dialog, and will never be annoyed by an unusable UI.

Boy, I hope they fix this before shipping. 😦

Read Full Post »