Wednesday, June 16, 2010

One man’s introduction to MVVM with Visual Basic story OR zomg a MVVM article that’s not in C#!

Alessandro Del Sole's Blog - WPF: Introducing the Model-View-ViewModel pattern for Visual Basic 2010 developers - part 1

“This is the first post of a new introductory series about the famous Model-View-ViewModel pattern, from the perspective of a Visual Basic 2010 developer. The reasons of this series are mainly the following:

  1. yes, there are tons of articles, posts, discussions about M-V-VM but most of them are for advanced users
  2. most of the available materials refer to Visual C# and there is not much VB code

Before going on, I suggest you to read the very famous article by Josh Smith on MSDN Magazine, which is probably the most complete article on this topic. Next, M-V-VM can be applied to both WPF and Silverlight, with some differences between the 2 technologies, but in this blog post series I will refer to WPF 4. I will also do some personal considerations during the explanation.

What is M-V-VM?

If you are existing WPF or Silverlight developers, probably you heard about the Model-View-ViewModel pattern. Such a pattern has the purpose of offering a high degree of abstraction between layers (such as data and presentation), so that inside the presentation layer the developer can write only UI-related code but not code for managing data. This is possible because of the powerful data-binding engine in WPF which allows to an intermediate layer (known as ViewModel), which is between data (Model) and the user interface (View), to execute required operatins through binding and commanding techniques.

M-V-VM is a pattern, meaning that it's a set of guide lines that will help you reach an objective. This also means that it is not the rule and that you do not need it always. In fact, there are some scenarios where M-V-VM is not the best choice.


M-V-VM is particularly useful for the following reasons:

  1. full separation between data and the UI
  2. full separation between the roles of developer and designer (which is also one of the primary reasons for XAML to be created)
  3. testing: as I will show you in the last part of the series, executing unit tests against a ViewModel makes sense instead of executing tests inside the UI context
  4. Model and ViewModel don't have the need of changing if the UI changes
  5. The ViewModel keeps the same logic independently from the kind of Model (e.g. custom business objects, Entity Data Models, etc.)
  6. better “Blendability”, which is the possibility of working on a project with Expression Blend

image …”

As you may know I’m a fan of MVVM. I believe it’s the real reason to move to WPF. Not WPF’s glitz, glamour and gee-wiz, but its data binding and commanding capability allowing for true decoupling our full/smart client presentation/views/UI from our code. Real and true no-code behind coding. True separation of design from code. That’s what draws me to WPF and models like MVVM.

MVVM has been gaining steam for a bit now, but for me the problem is is that most samples, chats, posts, etc are in C#.

As a VB, I’m okay at reading and doing mental runtime translation of C# in VB (as most VB’ers have had to learn to do in the past years), I still find it faster and easier grok something when its natively in VB. Which is what attracted me to this article… (gee, funny that… ;)


Related Past Post XRef:
MEF’ing in VB and SilverLight 4, with a little MVVM thrown in for flavor, from Glenn Block
SilverLight 4, RIA Services, MEF and MVVM, oh my… A four part series from the mind of Shawn Wildermuth (updated for VS2010/SL4 RTM)
MVVM Explained
The MVVM Framework Tour – This time, Silverlight styling!
A MVVM framework “…three hour tour…”
From code-behind to MVVM in 90 Minutes - Jason Dolinger on MVVM
The WPF Starter Kit – A simple, barebones, pick it up in an afternoon, MVVM/Navigation/Commanding Framework
M-V-VM for… um… busy developers (not dummies… not dummies… okay, so I’m a dummy! ;)


Rick Eberle said...

As a VB guy, I'm interested in your opinion of why MVVM vs code behind with WPF for a small 2-3 person programmer only shop is better. With no designers I'm having a hard time justifying it. Doing it only for the multiple UI possibility violates YAGNI in our case. To me it just seems to be an extra layer and extra complexity.

Greg said...

I'm also in a very small team and still have found MVVM to be useful.

a) Testability. It makes is easier to write unit tests for "UI" code (i.e. to test the view models)
b) Every small project seems to always grow into bigger ones. So I've found that MVVM helps keep the Technical Debt under control
c) MVVM just seems custom made for WPF and its data binding/commanding

Now do I think it's perfect? Oh hell no. There is way too much coding required to get started. You can tell this by the number of MVVM frameworks around.

But having a full client production app in every version of VB (1-10) I feel pattern/model driven coding, like MVVM, is a step in the right direction.

I've seen the initial "pain" pay off over time....

Unknown said...

For me one of the overlooked benefit for even a small project to use MVVM is to keep your XAML simple. Problems in code are easier to fix and understand than in a monolithic XAML markup. ViewModels help a lot in this endeavour.

BTW I have tried to explain MVVM for a Visual Basic programmer but this time with real Visual Basic i.e. VB6 :-) . Check here