Programming with MVVM Miguel A. Castro Architect -

ineta .NET Architect, Developer, & Trainer  Microsoft MVP  ASP Insider  VSX Insider  C# Insider  Azure Insider  Member of the INETA Speakers Bureau  Conference Speaker  In IT business since 1986

Have you seen this woman?

Agenda XAML Data Binding What is MVVM Implementing the Pattern (and sticking to it) Adding Commanding Unit Testing Advanced Features

Data Binding Extremely powerful with XAML Everything binds (to everything else) Every tag has DataContext property –Value becomes underlying binding source –Provides values from tag & down visual tree Underlying binding object needs to implement INotifyPropertyChanged interface

XAML Data Binding... ………………………………………………………………………………… this.DataContext = myObj; where myObj contains: string Name double Size

What is MVVM? MS Pattern based on Presentation-Model Class provides the binding source for the entire view Encapsulates logic for the view –Provides state and behavior –Logical representation or UI Loosely coupled to the view

What is MVVM? ViewModel Layer View (XAML) Layer

Goals of MVVM Make the view “State Driven” Fill in for model short-comings Decouple state and behavior from view Provide ability to unit test Allows the engineering of the UI to take place in an object-oriented fashion –VMs are logical representation of UI Reduction or even elimination of the code- behind class

Rules of MVVM ViewModel should have NO knowledge of the View View should have a loose coupling to ViewModel (not until runtime if possible) ViewModel can expose individual properties or model as a single property

Implementing the Pattern A ViewModel is just a class that –Wraps one or more domain models –Provides property notification –Provides validation notification (optional) –Exposes bindable properties (or model) –Contains commanding behavior –Can be tested completely independent of the view –Can fire events back to the view

Connecting to View ViewModel class becomes the “DataContext” of the View –Window or UserControl Can be set anywhere convenient View can optionally hook into ViewModel events –Used for navigation to other windows

IMPLEMENTING THE MVVM PATTERN Demo

Commanding XAML Technology –Not specifically MVVM-related Works great with MVVM (eventually) Command classes –Inherit ICommand –Used with implementers of ICommandSource Provide execution and determination of execution

COMMANDING Demo – Commanding Basics

Commanding in MVVM Usually a command needs access to ViewModel state –Ex: Saving of data entered by user Command classes don’t “belong” to a ViewModel Need way to hook classes together –Command execution needs to access VM state

Commanding in MVVM Technique 1: –Receive copy of ViewModel into command constructor Technique 2: –Use Delegate/Relay Command pattern –Allows passing of method pointers into command Methods reside in ViewModel Which technique is used depends on command reusability necessities

COMMANDING Demo – Commands MVVM-Style

Putting It All Together Think in State-Driven terms If View has requirement, ask: –What state and behavior does the ViewModel have to expose in order to satisfy the requirement? Exercise –Provide a view with a label to be displayed in one of two colors –Provide two buttons used to alter the colors of the label –Enable or disable the buttons accordingly when not useful –Allow for proper unit testing

Before & After MVVM BEFORE View shows label and buttons Button click events change color of label Button click events disable button just clicked and enable other button AFTER View shows labels and buttons View bound to ViewModel Label color bound to property Buttons bound to commands Command argument provides color Command execution changes color property Command determination depends on current color

MVVM EXERCISE DEMO – Before & After MVVM

Unit Testing ViewModel is totally decoupled from View Has no dependency on View class Can even reside in separate assembly Can be instantiated like regular class Unit test can test properties (if needed) Unit test can set state and call upon command execution

UNIT TESTING DEMO

ViewModel-First Views contain other Views Same hierarchy for ViewModels –ViewModel exposes other ViewModels as state Commands cause ViewModel “flipping” Data Templates provide VM-V mapping –Silverlight requires a Type-Converter technique Can concentrate on the logic of what ViewModel to use when and why – independent of actual View that will show

VIEW SWITCHING DEMO – ViewModel-First

Where to next? Further technologies intertwined with MVVM –Type Converters –Validation Techniques –Design-Time Data –Dependency Injection –Frameworks

Frameworks Domain-Framework Core-Framework ViewModelBaseViewModelBase Customer- ViewModel TabbedViewModelTabbedViewModelDialogViewModelDialogViewModelToolViewModelToolViewModel RibbonTab- ViewModel Undoable- ViewModel SaveableTabbed- ViewModel Page Conductors Validation Rules View Bases Type Converters Event Argument Classes EnumsEnums CustomerGenInfo- ViewModel CustomerProfile- ViewModel CustomerOrders- ViewModel CustomerBilling- ViewModel Relay Command ModelBaseModelBase ObjectBaseObjectBase

Frameworks MVVM Foundation MVVM Light Caliburn CSLA Prism

Finalizer ViewModels provide a great binding source for XAML views Decoupleness allows easy testing Can set up ViewModel inheritance chains for commonly used state or behavior –Not possible with code-behind Much cleaner design Take the time to setup MVVM – it’ll be worth it Use or build a framework – at minimum, a base layer

Finalizer Let your ViewModel evolve naturally Think about ViewModel inheritance where applicable Don’t concentrate on code-behind elimination –It will happen naturally and eventually –In most cases, you may start out never using code-behind Don’t forget your unit tests –Should have one unit test per-ViewModel

References Josh Smith’s Blog – In the Box – MVVM Training –Karl Shifflett – the-box-ndash-mvvm-training/ the-box-ndash-mvvm-training/ –Full kudos for the MVVM Before/After exercise TONS of MVVM stuff on the web

Miguel A. Castro Thank You