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.