Why MVVM?

There are many design patterns available when implementing a universal application in Windows. The more common design patterns include Model-View-Controller (MVC), Model-View-Presenter (MVP) and, of course, Model-View-ViewModel (MVVM). MVVM is the more commonly used design pattern in Windows 8+ universal applications. This is due to its ability to decouple the business logic and view logic of applications in a way that provides the most reusable code across the two primary platforms - phones and tablets/pcs.

What is MVVM?

There are numerous blogs available that detail all of the principals of MVVM so I won't go into too many details. MVVM dictates that the application should be split into three primary components:

Model: The model provides the entities that are used throughout the application. This is typically comprised of a database and its entities and/or services and their data transfer objects (dto's).

View: The view, as the name suggests, is all of the user facing application logic. In Windows universal applications this would be all of the XAML and code-behind that generates the application's user interface.

ViewModel: The viewmodels of the application provide the glue between the model and the views. Most of the application's true business logic will be contained within the viewmodel layer.

Structure

Once the principals of MVVM are understood, the structure within universal applications is very straightforward. The application should, at a minimum, have a clear separation of each of these components. I prefer to maintain Model, View and ViewModel folders at the root of the application to keep this separation clear. This should be done for each project if implementing a true universal application (phone, tablet/pc and shared projects). Not everything will fit within the scope of these folders, but in general there shouldn't be too many additional folders at the root of the application.

Services

Since universal applications share logic between the phone project and the tablet/pc project, it is important to reuse as much code as possible. To do this, all of the viewmodels should be implemented within the shared project. Since there are still different backend libraries between phones and tablets/pcs for some of the cross-cutting functions needed in the viewmodels, these viewmodels will sometimes need to have different code for each platform. I refer to these needed cross-cutting implementations as services and they typically include things like a navigation service for page navigation, a notification service for alerts, dialogs and errors, and a settings store service for providing an application's and/or user's settings. These services can mostly be implemented within the shared project but more than likely there will be situations where you will need to create partial method implementations within the phone and tablet/pc projects as well. These services can be utilized in the viewmodels, preferably by using dependency injection. I usually dedicate another folder at the root of the application just for these service interfaces and implementations.

Additional Thoughts

The platform for universal applications is still being developed. Although it is easy to implement MVVM with the raw Windows SDKs, there are many frameworks and toolkits available to help fill the gaps for missing functionality and bootstrap code. MVVMLight is one of my favorite toolkits since it provides some helpful classes to reduce coding time but it doesn't bloat your application with unnecessary code and libraries.

Remember that MVVM is a guideline to help maintain separation of concerns and decoupling in your code. Although often times it will be easier and quicker to break the MVVM structure, in the long term it provides a very scalable, flexible and organized way of implementing a great Windows universal application.