or How I Learned to Stop Worrying and Love the Binding Bryan Anderson

Consultant for ILM Worked with WPF & Silverlight for the past 2 years In industry for 4 ½ years Programming for 14 years Of all of the features to come to.NET 4.0, Code Contracts are the most important

Vocabulary & relevant Design Patterns Presentation Model pattern MVVM Architecture Compare MVVM to MVC Religious fights you’ll encounter when implementing MVVM Common issues you’ll run into with MVVM and their solutions

//Notifies clients that a property value has changed. public interface INotifyPropertyChanged { //Occurs when a property value changes. event PropertyChangedEventHandler PropertyChanged; } //Notifies clients that a property value has changed. public interface INotifyPropertyChanged { //Occurs when a property value changes. event PropertyChangedEventHandler PropertyChanged; }

//Notifies listeners of dynamic changes, such as when items get //added and removed or the whole list is refreshed. public interface INotifyCollectionChanged { //Occurs when the collection changes. event NotifyCollectionChangedEventHandler CollectionChanged; } //Describes the action that caused a CollectionChanged event. public enum NotifyCollectionChangedAction { Add, Remove, Replace, Move, Reset } //Notifies listeners of dynamic changes, such as when items get //added and removed or the whole list is refreshed. public interface INotifyCollectionChanged { //Occurs when the collection changes. event NotifyCollectionChangedEventHandler CollectionChanged; } //Describes the action that caused a CollectionChanged event. public enum NotifyCollectionChangedAction { Add, Remove, Replace, Move, Reset }

Keeps data in two properties “bound” together Allows data to flow in either or both directions Uses PropertyChanged & CollectionChanged to keep values updated

Implements IValueConverter or IMultiValueConverter object Convert(object value, Type targetType, object parameter, CultureInfo culture) object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) Converts inputs from one value to another and back Used extensively in data binding

Looks like a standard CLR property on the class’s interface Adds additional infrastructure features like Data Binding Change Notification Value Coercion Used extensively by WPF and Silverlight to create fast, reactive user interfaces

Groups a related set of controls Reduces repetition – DRYer Has its own code behind – allows new dependency properties

An implementation of the Command Pattern In WPF & Silverlight the ICommand interface is used to define a class that represents a command bool CanExecute(object parameter) void Execute(object parameter) event EventHandler CanExecuteChanged Frequently implemented by creating a DelegateCommand class

Design patterns give programmers a proven solution to a given problem with known benefits, drawbacks, and a shared vocabulary. Command – Encapsulates method calls Mediator - Encapsulates messages between objects Adapter – Translates one interface into another Façade – Simplifies a larger interface Singleton - Restricts a class to a single instance Factory – Encapsulates the creation of an object Etc.

Architectural patterns serve the same purpose as other design patterns, but they focus on the whole application or a very large portion of it.

Guide the separation of concerns Encapsulate what changes UI Web services Databases Anything else that interfaces with something outside the application

Separate presentation from functionality Testability Consistency Maintainability Allow a combined Blend/Visual Studio workflow

Abstract Pattern that defines a family of platform/framework specific patterns MVVM – WPF, Silverlight MVC – Web MVP – Winforms Designed to pull the state and behavior out of the View into a more stable and testable layer Model Presentation Model View

Model Presentation Model View

Model View Model View Unit Tests Web Services File System Database Responsible for business logic Interacts with persistent storage, e.g. database, web services, files, etc. Capable of being shared among related applications

Model View Model View Unit Tests Web Services File System Database Should be thought of as an Abstract View Exposes properties and commands for use in a View Gets data from the Model and updates it according to property changes and command calls

Model View Model View Unit Tests Web Services File System Database Presents data to the user Handles input Interacts with the View Model by data binding to properties and commands Should contain no logic that isn’t entirely a view concern, e.g. which screen to show

Model View Model View Unit Tests Web Services File System Database Acts as another View Interacts with the Model and View Model to ensure correct behavior Provide an early warning that the architecture isn’t correct If testing is difficult, coupling is too high or concerns aren’t separated

The Model holds data and handles business logic The Controller receives input and makes changes to the View and Model accordingly The View renders the Model into a form suitable for interaction Model Controller View

Multiple, mutually exclusive options People form strong opinions and will argue the benefits of their choice for all eternity Each side has its own benefits and drawbacks A decision needs to be made before the “correct choice” can be determined In the end it comes down to a combination of reason and instinct

View Model Driven Allows more complete testing of logic to open new Views/View Models Tends to be DRYer as applications grow More difficult to use in Silverlight projects View Driven Easy to track which View Model is used by a View Much easier to use when sharing code between WPF and Silverlight Difficult or confusing for a single View to be used with multiple View Models

How much code should I actually have in the View’s code behind? Value converters are fine as long as they’re only converting values User Control code behind should only contain Dependency Property definitions and rare view- specific event handlers DataTemplateSelectors as long as their code is limited to choosing between DataTemplates Otherwise there should be no code-behind

Should the View be allowed to use/display a Model class directly or should all interactions be through the View Model? The View should never edit a Model instance My rule of thumb – Only allow the view to display immutable Model objects, even then try to avoid it It should be considered technical debt if done, but it’s a relatively harmless area to take on debt

Where should INotifyPropertyChanged and INotifyCollectionChanged be used? Definitely in the View Model Occasionally in the View - usually in Custom Controls and more rarely User Controls It’s becoming more accepted to them in the Model unless added to push updates to a View

Notifying users from a View Model, i.e. How do I show a message box? How do I handle non-command events without code behind? Something should or should not be shown based on state. What goes in the View vs. View Model? Should I use an additional property or the command parameter to pass contextual data to a View Model’s command? View Models seem to copy all of my Model’s properties

Message boxes are annoying

Messages to the user are useful Use a mediator – Allows you to aggregate messages from all of your VMs, log them, and display them. Also easy to test. If you only need it in one or two places an Error/Notification property or, more rarely, event works well. Implement the IDataErrorInfo interface for notifications related to property validation

Usually done using an attached behavior, search for “Attached Command Behavior” Can it be handled by binding? If absolutely necessary and there’s no logic involved it can be put into code behind.

Is it a View-only concern? E.g. Master/Detail view Bind the detail view to the selected master item Is it a View Model concern? E.g. IsEditMode Use a DataTemplateSelector if available to switch Views Use Triggers, Visual State Manager, or another method to switch views based on the View Model properties Is it a combination? E.g. IsBusy Use the Visual State Manager if available

Would the property be referenced anywhere outside of the command(s)? Does the property make sense in the context of the View Model’s interface? Is the command used in multiple places that would need to set the property to different objects?

View Models are not just Façades or Adapters for Model classes View Models are not the code behind for a View View Models are an Abstract View or the Model for a View View Models will present multiple Models and multiple View Models might use the same Model

I love feedback! Bryan Anderson