Xamarin Forms - MVVM
MVVM Overview
2m 49s

The course is part of this learning path

MVVM Overview

This course looks at the Xamarin Forms implementation of the Model-View-ViewModel architecture, paying special attention to data and command binding. We see how to bind view models and nested models to views, and explore notification mechanisms built into the Xamarin Forms core for bi-directional data and view updating. The course also looks at XAML markup extensions and value converters for displaying images within a Xamarin Forms app.

Learning Objectives

Understand the model and view model aspects of MVVM and create an application using the Flyout app template

Intended Audience

This course is designed for anyone interested in enhancing their knowledge of Xamarin, with a focus on MVVM.


To get the most from this course, you should have a basic understanding of interfaces and reflection in the context of C# and .NET.

Source Code


Design patterns are templates describing how an app's source code should be structured when building the application. I say source code instead of code, as the primary purpose of a design pattern is to organize the code's structure to make it easier for developers to understand and navigate. Once the code is built into a functioning application, the CPU doesn't care how the source was structured. 

There are a lot of design pattern acronyms out there, like MVC, MVP, and MVVM, but they all have some key aims in common. Divide code into blocks or files where each code block is responsible for a single action or has a single purpose. This code division is often referred to as "separation of concerns," meaning each code block should only be concerned with one task. In modern software development, where Test-driven development and targeting multiple platforms have become the norm, this separation serves multiple purposes. It's much easier to test one piece of functionality at a time and debug a small and focused code block. When targeting multiple platforms, the back-end code may be common for all targets, and only the user interface needs to change. It is much easier to allocate tasks to multiple developers when you can assign discreet and self-contained modules of work.

Whether we're talking about MVC or MVVM, the model and the view are the same. The model is essentially the data in the form of an object. The model code retrieves and persists the data from an external source, be that an API, database, or web service, but presents it internally as an object. The view is the user interface or GUI. It is the code that glues the UI to the data where most design patterns diverge.

Data binding is a key aspect of the MVVM design pattern. In older software methodologies, when the developer wants to put some text on the screen, they need a line of code that assigns the text to a field. Conversely, getting data from the UI involves interrogating the user interface and retrieving the data. In unsophisticated UI code, all model data may be updated when the user clicks save, leaves the screen, or some equivalent. A more sophisticated method is to monitor UI fields for data changes or user interaction and then update just those fields where the data has changed. This approach falls under the category of event-driven programming. Data binding is a refinement of the event-driven approach where the developer doesn't have to write event monitoring code. There is no need for OnKeyDown events with all the associated character checks. Using special syntax in the Xaml UI, you "bind" view model properties to UI controls. Data binding frees the developer from relatively low-level event programming by keeping ViewModel data "auto-magically" synchronized with what's displayed on the screen. ViewModel binding can work in both directions, meaning once bound, you only have to populate the ViewModel with model data, and it will appear in the UI. 

The ViewModel layer enables easy mapping of data models onto UI. Often an app's data resides in a relational database where data is stored in such a way to reduce repetition. If your model uses object-relational mapping software like EntityFramework, you'll probably have many small models that don't map well onto software objects in the UI. The ViewModel is where you can transform a normalized data model into an instance of a software class that represents a real-world object.


Let's head over to Visual Studio and see Model-View-ViewModels in action.

About the Author
Learning Paths

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard. 

Covered Topics