Model-View-ViewModel (MVVM) – Part 1

I have been working with MVVM for about a year now as part of work related projects. For the larger portion of my career I have focused on Model View Controller or Model View Presenter schemas for user interface. However, after learning as much as possible about MVVM from experts around the web, I have adopted it as my primary method UI implementation.

So what is MVVM? For the most part it is MVC on steroids, it is a way to split presentation design from codified logic specific to the application. In WPF, it allows easy access to core features such as databinding. It allows the developer to write UI seperately from business logic, which seperates the visible behavior from the logical behavior of the application. A nice side effect is unit testing of the application becomes much easier, since most if not all application logic is handled as methods. It is easier to describe in parts:

ViewModel – is the entity(ies) that the application is trying to manage and consume

• This is your entity class, everything here should be Properties.

View-Model – is an intermediary layer where most of the logic live for specific business applications.

• This layer is not aware of UI controls.
• Here you expose Public properties that the UI layer will be bound.
• Use public methods invoked by events/commands
• Update the View through databinding
• Update the Model through bound properties

View  – is how the View-Model is displayed, the UI.

• Contains the XAML in a WPF application
• Command bindings – routed commands
• Property bindings
• Code behind should be as clean as possible
• Should include basic wiring to instantiate the view
• General Rule of Thumb – if you have x:Name in your XAML, you are doing it wrong.

In the next article I will demonstrate the view model base class.