MVVM – Introduction

Hello, Good Evening and Welcome

You might be asking why the world needs another programming blog. Over the years, I’ve come across many C# developers interested in learning WPF (or other Xaml platform) / MVVM development, but lacking that initial “getting started” knowledge. I’ve decided to collate some of my experiences into one place, that hopefully will provide such a resource.

This blog is aimed at developers with existing C# experience – either Winforms or web. Perhaps you’ve already dabbled with WPF, and (like me for a long time) haven’t really seen the benefits of it over other U.I. platforms – hopefully these posts will convince you that it’s worth another look. All of the code examples will be written for WPF, although most of the techniques I’ll talk about will be equally applicable to UWP and Xamarin applications.

As my programming career has largely been spent developing applications for business users, rather than home consumers, I’m going to focus on the core functionality, rather than “visual fluff”, although the techniques I’ll be describing can be applied to all types of development projects.

As with many other aspects of life, there is often no single right answer to a development problem (although there are plenty of wrong ones). The application structures and techniques I’ll be describing are what has worked best for me. Don’t take my words as gospel though, feel free to pick and choose what suits your own needs.

Why WPF & Xaml?

For many years as a C# Winforms (and previously Borland Delphi) developer, I followed that familiar U.I. design paradigm, where controls are laid out precisely pixel by pixel. In an ideal world this works fine, but most development environments are far from ideal. How many times, after you’ve spent forever designing a complex form, has your boss said something like “can you make the font of that label a bit bigger, and change the text slightly …”, which requires the position every other control on the form to be adjusted, in order to keep everything aligned. Life gets even more complicated when you have to make your application multi-lingual, or to cater for users running with extra large fonts.

With Xaml, the layout becomes much more straightforward. You can define a block of text with a style / margin, and the rendering engine will calculate the space required and automatically adjust the position of other controls so that everything fits as well as possible, within the specified constraints.

You can also do some things in Xaml that just aren’t possible in say Winforms. What if you want to display a collection of objects in a ListBox? In Winforms you can have a single static string value for each item (e.g. Person.FullName). However, with WPF data templates, you can build a composite layout using any combination of controls – each bound to a different property of your object and with their own style / font / colour, all using the current object state. Or, how about a button with an image and multiple lines of text, where one line of the text changes colour, depending on some other state in the application. With WPF, the only limit is your own imagination. [Ok, so you can do an “OwnerDraw” ListBox in Winforms, but that requires way more effort than producing the equivalent display in WPF].

You might be worried that switching from Winforms to WPF will be too steep a learning curve. The new U.I. techniques may take some work to grasp, but given a little practice, they will soon become second nature.

“What about all my other C# code?” I hear you ask. Well, if your application is talking to a database or a web service, or performing some complex numerical processing, then you can use exactly the same C# code in your WPF project. It’s only the U.I. layout and the application structure that changes – the rest of your C# code will remain exactly the same.

Why MVVM?

MVVM (Model – View – ViewModel) is an application design pattern, initially created for WPF / Silverlight development. Its primary goal is to provide a clear separation between the application data (Model) and the user interface (View). The ViewModel is an intermediate layer that presents the application data to the U.I. via data bindings, and provides a command structure for the U.I. to trigger application processing. Although it’s possible to do WPF development the “Winforms way” – writing code to set control values directly from the data and trigger processing directly from event handlers, to do so would be miss out on the the key features of WPF. This separation also allows for the data access and processing to tested without any U.I. in a TDD environment. In theory, you could take your Model & ViewModel and stick a console window on the front – OK, so it wouldn’t function so well or look very pretty, but you could make it work. Also, should you wish, you can split the development – passing on the Xaml design to a more creative member of your development team, while you’re working on the functional code, without the two getting out of sync.

The key to MVVM is the INotifyPropertyChanged interface (and to a lesser extent INotifyCollectionChanged). PropertyChanged is like a broadcast message – “Hey to anyone that’s listening, this named property value just changed”. It doesn’t care who is listening (there may well be multiple listeners for an object / property) and what they might do with the notification. Its most common usage is to trigger the redraw of a U.I. element, whenever the value of a bound property of the ViewModel is updated, without having to write any additional code.

Contrary to popular belief, MVVM does not mandate zero code in the U.I. layer. There may well be some cases where you have to write C# code in the view class, but it should be solely what is required to make the U.I. work, certainly not any business logic or other data processing.

Do I need a MVVM Framework?

You don’t actually need a framework to follow MVVM – you could write your own base class to implement the core INotifyPropertyChanged interface, and all of the other helper classes you might need. However, I’m a strong believer in not re-inventing the wheel. If someone else has already done all the hard graft, why not use it – especially for those libraries that have source code available so you can see exactly what’s going on under the surface.

MVVM is merely a design pattern – there is no single “official” MVVM library. There are many packages and toolkits to help implement MVVM such as Caliburn Micro and Prism (click here for a fuller list). Having tried a few different MVVM libraries and frameworks, I’ve chosen Laurent Bugnion’s MVVMLight for my own work. I’ve found that it provides just enough tools to help implement MVVM, without taking over the entire application. MVVMLight can be installed via Nuget, and the full source code is available to download from Github, if you want to see what’s happening inside the DLLs.

Over the forthcoming postings on this blog I’ll be introducing some of the features of the MVVMLight package, as well as my own C# / WPF / MVVM library that extends and complements it. All of the code samples for the posts are available on Github

If you find this article useful, or you have any other feedback, please leave a comment below.