Almost all of my projects involve the designer/developer workflow to a certain degree (even if I end up doing both roles!) and the UK Solutions Delivery team has spent a number of years developing best practice for this style of work.
There’s a range of skill sets in this area from designers who hand over designs in PhotoShop files, to developers who work completely in C# and never touch XAML or the UI design.
The Designer/Developer workflow focuses on people who fall between these extremes. WPF and Silverlight, with the use of Blend, lend themselves very well to this method of working and the UK UX team practices and supports it on a daily basis.
I was introduced to the Model-View-ViewModel design pattern shortly before beginning work on the Eye on Earth project. As it was a user centric agile project, it made sense to use MVVM.
Model-View-ViewModel is a design pattern used in Silverlight and WPF development to assist the designer/developer workflow. It separates the UI, control and data further than using XAML and code-behind files does, aiming to provide a consistent and flexible project structure. MVVM is also geared towards UI unit testing as the layers can be separated to test upon.
The ViewModel holds the MVVM pattern together. It exposes properties which elements in the View can bind to, providing both control of the UI and a representation of the data.
INotifyPropertyChanged must be implemented and this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)) called whenever a property is updated to ensure the View refreshes accordingly.
For example, a bool IsPanelVisible property may store whether a panel on the UI is visible and a ObservableCollection<string> WordList may store a list of words.
Several VMs can be used for each logical area of the UI and calls can be made between them, to change properties for example.
The VM is also used for processing and generating any calls to the model to request data.
The View comprises of XAML, controls, resources, templates, styles – anything that a designer may want to change in Blend. Normally little code would be written for static pages, often just event handlers which would call into the ViewModel.
The data context for the View is set to be the instance of the corresponding ViewModel and elements are databound to the VM’s properties. Converters can be used if the types in the VM do not correspond.
For example <Border Visibility={Binding IsPanelVisible, Converter={StaticResource VisibilityConverter}}”> would give control of the particular panel’s visibility to the VM.
By two-way binding a checkbox to IsPanelVisible, the user would be able to turn the panel on or off - just using data binding.
Binding can also be used for data: <ListBox ItemSource={Binding WordList}” /> would display the list of words stored in the VM.
Controls and user controls will generally need some code to make them work and this is where I feel some confusion was created when I tried using the pattern. I attempted to do as much as I could in the XAML and ensure there weren’t any dependencies on other parts of the MVVM created in the code.
Templates, styles etc. are done in the normal way by a designer in Blend.
The Model is used for data and has no direct link to the View. Requests for data are sent to the Model from the ViewModel and events are triggered once the data has been returned. This data is then sent to the VM for processing.
We used the Model to make calls to a variety of WebServices and to access Silverlight’s isolated storage.
A great thing about the Model is that it abstracts the data away from the rest of the UI meaning it could come from anywhere. We set up a MockModel to provide sample data to the VM which meant work could be done on the UI before the backend was in place. Creating an interface for the Model and MockModel ensured that we had stubs in place on both of them.
There is definitely an initial overhead to using the MVVM design pattern as it takes time to set up the structure. There is also a small overhead throughout the project as more thought is needed when building the UI – not that this is a bad thing!
My experience of using the pattern has been very good. The designers I’ve worked with have been able to use Blend to alter the XAML without worrying about data or control and backend developers were able to hook up their web services in C#.
The overall structure of the project seemed more professional and thought through although sometimes there were times when we had to work around the pattern to get something done.
All in all, I would recommend giving it a go. I’m using it again on my current project based on previous experience and things are running smoothly!