Making WPF MVVM Approachable

gozirra

Over the years, software developers using Microsoft toolsets have come to be increasingly skeptical of new Microsoft application architectures – Silverlight immediately comes to mind. For many, WPF (Windows Presentation Foundation) fell under similar suspicion. But WPF has survived as the key successor to Windows Forms, and has an important role to play. In fact, the building blocks associated with WPF – XAML, data binding, Entity Framework, and MVVM (Model View ViewModel) – are important career-building skills that open doors beyond Microsoft environments.

WPF acceptance has been hampered by a perception that it’s unnecessarily complex. Just enter “WPF learning curve” in a search engine, and you’ll see what I mean. I experienced this personally as I worked through books, on-line courses, and example code. The main factors in this unnecessarily difficult curve are: 1) obtuse terminology, 2) wide variation in structure of app’s, and 3) a jungle of different options in implementation.

In our development group, we’ve invested the time to cull out the key concepts of WPF, especially MVVM, and have distilled them into our own framework. We can now build maintainable WPF app’s that stand up to current standards and have a well defined structure. We call our implementation “Ambience”, due to our replacement of the term “ViewModel” with “Ambient”. Here are the key components of this framework:

“View” – User interface controls consisting of XAML and minimal code-behind. Data is presented and manipulated through property bindings, command bindings, validation rule bindings, and style templates.

“Ambient” – A replacement for the term “ViewModel”. We use it as a noun, since it provides the ambient environment for a given view. This includes any properties, collections, commands, and validation rules needed by the view. It is the data binding context for its associated view.

“Entity” – Objects classes defining the objects used by ambients and stores (see below). These are as simple as possible, ideally consisting of properties and attributes, and no methods.

“Store” – Interfaces and implementations of classes that provide access to data. Most commonly stores are Entity Framework objects used to read and write to databases, but can also include access to web services.

“Helper” – General purpose classes for such things as logging, configuration files, and encryption.

By using this basic and easy-to-understand terminology and structure, WPF is not quite so intimidating. Other steps we take to flatten the learning curve include direct editing of XAML with minimum use of the designer (dependence on the designer just prolongs your pain), avoidance of event handling, division of interfaces into simple user controls, data validation through bound validation rules, and XAML styles and triggers.

So assemble interested members of your development team, establish your own framework, and make the transition to XAML views, ambient contexts, and binding in WPF. As a result, doors will open to improved testing, better separation of concerns, and higher quality code.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s