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.

Benefits

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

…

…”

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! ;)