MVVM frameworks for Windows RealTime (Universal Apps): which one to choose?

Windows Runtime Templates for Windows 8.1

I am looking for the most appropriate architecture for a new project that has the following requirements:

The app will include more and more new features in the future and it should be maintained also with next releases of Microsoft operating systems (on smartphone, tablet, PC): therefore, all the used components must assure to be able to evolve also with future versions of the underlying O.S. and guarantee a support in the future.
The developer team could change during the long life time of the app, so new developers, expert in Microsoft technologies, should be able to become productive in a short time, being the structure of the solution flexible and possibly easy to be understood and used for further development and bug fixing.
The platform target is now only Windows Phone 8.1 but, in the near future, there will be the need to consider also a tablet/desktop version for Windows 8/10.

I was already oriented to use Windows RT (not the agonized Silverlight), the Visual Studio template related to Universal Apps (to leave the solution open for the future development of a version for the Windows platform), a multi-tier architecture and the MVVM pattern (to have a separation between views and code, in order to possibly reuse the same logic in the shared project, not having it embedded in the code behind).

If you are interested in developing Universal Apps, may be you can also have a look to the following post I wrote some weeks ago: Windows Phone 8.1 – Some useful links for developing Windows “Universal Apps”.

=============================================================

The first question is: why using the MVVM pattern in developing a Universal App?

First of all we should say that MVVM is a convenient design pattern for implementing the data driven views inside a xaml application. The use of the MVVM pattern it not even to be discussed because nowadays every complex app (that it is not an Hello World one, I should say) use it.
Moreover, the use of this pattern is even more relevant in Universal Apps (so having the app available for both smartphone and tablet/PC), where there is the need to share as much code as possible between the Windows Phone and Windows projects and not always it is possible, convenient or easy to have a single xaml in the shared project so only the ViewModel, containing the page logic, can be shared: that is why the first suggested step to make a porting of an existing app as a Universal App is to possibly move to the MVVM pattern if the pre-existing project was not so structured.
However let’s try, in the following, to give a more formal answer to the initial question …

In general patterns and best practices will actually slow down initial development and that’s often a hard sell to management and engineering alike. The payback (ROI in biz terms) comes from having well-structured code that is actually maintainable, scalable and extensible. Moreover they give a way of work that all the developers of a team must follow, in order to have a common structure in the whole solution, helping to have the development of a single component (and related testing) independent from the others: this can help also if the developers will change during the evolution of the app, requiring that also the new ones must follow the same developing approach, even thought the needed skill should be higher. I think that also this last benefit is relevant to avoid that every new consultant possibly adopts his own personal way of programming and structuring a project, may be criticizing the architecture chosen by previous developers …

In traditional UI development, a View written in XAML have all the logical code (e.g. event handling, initialization and data model) in the code behind and hence the code is a part of view definition class itself. This approach increased the size of the View class and created a very strong dependency between my UI and data binding logic and business operations. The event handlers are tightly coupled to the controls, and typically contain code that manipulates the UI directly. This makes it difficult or impossible to replace a control without having to update the event handling code. So everything is in one place and this is always a bad idea for maintainability, extendibility and testability prospective. So if you look at the big picture, you can feel that all these problems exist because there is a very tight coupling between View (UI), Model (Data displayed in UI) and “glue” code (Event handling, binding, business logic): in MVVM the “glue” code is View Model. So MVVM pattern basically focuses on separation of concerns to make the implementation of an application structure simpler to create as well as to be maintained. It organizes your code so that you can change individual parts without affecting other parts. The ViewModel code can be written without having a reference to graphic and UI controls. The primary purpose of MVVM is that the code is broken up into classes with a small number of well defined responsibilities. One of several benefits of having code consisting of classes with a small number of well defined responsibilities is that it is easier to be implemented in a team and to put the code under Unit Test. A much larger benefit is that the code is easier to understand, maintain, and modify, … obviously once you known the used framework! So:

Would you like more flexibility to change your user interface without having to refactor other logic in the code base?
Do you require thorough unit testing for your solutions?
Is it important for you to have reusable components, both within and across projects in your organization?
Do you need to share a project with a designer, and have the flexibility for design work and development work to happen near-simultaneously?

If you answered “yes” to any of these questions, these are just a few of the benefits that using the MVVM model can bring for your project.

For more detailed reasons you can find more and more resources in Internet that better than me can explain everything (e.g. the following posts: MVVM) Explained; MVVM e Windows Phone; or, even better, the video MVVM Best Practices that clearly explain what MVVM is and what it isn’t).

Surely following the MVVM pattern is not enough for having a well structured solution: we should also need to take into account a multi-tier architecture and a clear separation of the logic (business, data access and services) in classes with a small number of well defined responsibilities, wrapping the complexity of some work into well defined objects: … and probably this is even more relevant than having only a MVVM framework! For example (see chapter 23 of Daniele Bochicchio ‘s book and related samples), it is visible to have one proxy object class for handling each remote service [e.g. public async Task Login(Credential userCredential)] but also having the real call to the remote service done by an other object [e.g. HttpChannel : IChannel] in charge to implement all the details of the network usage (e.g. timeout, connectivity problems, error handling) and that exposes methods that will be used by all Service classes. This way of programming the network infrastructure layer, let you wrap in one object all the complexity of a network call so that other objects/methods can call the network stack (may be different endpoints) and have centralized the call logic, errors and possibly caches; moreover it allows to possibly inject the call logic (e.g. have a specific Channel able to read the same json/xml from file system, in order to take advantage of data caching).

=============================================================

Then, let’s go to the next question: what MVVM pattern implementation should I use?

Before choosing the final architecture I considered the main MVVM frameworks available for Universal Apps (MVVM Light, Caliburn Micro, Prism) and I tried to use some of them: I also considered the possibility to implement a custom MVVM framework from scratch to have, maybe, more control on the code.

In the following I’ll try to summarize my feeling, also taking into account the answers I received from some Windows Phone MVPs I contacted. The content of this page will be updated whenever I have some new input (e.g. testing whenever architectural solution): please feel free to add comments to this post if you disagree/agree with some of my statements and possibly propose alternative point of view!! 😉

================

First of all we should say that Visual Studio 2013 and the Windows Runtime do not offer tools for implementing the MVVM (that it is only a pattern architecture) but simply the XAML and C# only provide some functionalities that are the basis of every MVVM pattern implementation (e.g. binding, DataContext concept, INotifyPropertyChanged interface).
Note that the two classes that Visual Studio automatically create in the common directory, using an Universal App template, are only two helper class to support binding and suspension management … but this is nothing to deal with the MVVM pattern because they cannot avoid to leave at least some code in the code behind: these classes supports the MVVM pattern only for simple use cases . We can say the same for all the samples that comes with the SDK itself, that have only the goal to let the developer understand, in one o very few xaml View pages, the capabilities of a specific control/feature of the platform and nothing more: so, they do not have a structure visible for a real world complex app.
On the contrary, all the toolkits/framework (e.g. MVVM Light, Caliburn Micro, Prism) use functionalities to offer some helpers that simplify the adoption of the MVVM pattern. All these frameworks do not have a direct support from Microsoft (even though Prism is realized by the Pattern & Practice Microsoft division) and so there is not from Microsoft any official guarantee of their future: however they are all open source, very well documented and supported by a wide community. All of them has been evolved following the changes of the underlying Microsoft technologies: in fact, all of them already support Windows RT and the Universal App development, that is the most recent “vision” of Microsoft. Because they are based on the basis of Microsoft technologies, the possibility that they will stop to work properly in the future could be only if Microsoft will completely change the fundamentals of his XAML technology … and this eventuality is very very low.

The disadvantage not to use an already existing framework is that you must “reinvent the wheel“, because there are a lot of common scenarios (e.g. navigation, parameter exchange, suspension/resuming recovery) that cannot be simply managed with the basic tools provided by C# and Visual Studio: therefore, especially for a complex app, you would need to implement anyway your “handmade” MVVM framework to handle all that scenarios. This can give you the advantage that you have the full control on that framework BUT, in case of problems, you would have to solve them yourself, being a proprietary solution. On the contrary, existing frameworks are widespread used, there are forum where you can ask a support and there are documents to learn how to use them: moreover they are all open source projects, so if you need to add/change some functionalities, you can do and possibly contribute to the evolution of that framework itself.

Then, let’s consider the relevant MVVM existing frameworks (MVVM Light, Caliburn Micro, Prism), reminding that they are only libraries that give us a layer over the basic framework functionalities, that is the needed layer without whom it not visible to have a complete MVVM pattern support. As I have already said, they are all very well supported and maintained frameworks, they reacted at every changes of the platform and now they all completely support Universal App developments: but obviously there are different …

MVVM Light provides very basic tools, nothing more than some classes to make the INotifyPropertyChanged easier. It is the simplest one and easily to learn and use: this is also the reason why it is the most spread framework. It is not really a “framework” but a “toolkit” (and so it is called!), that is a set of components helping people to get started in the MVVM pattern. It is a light and pragmatic and contains only essential components. It is maintained by Laurent Bugnion who is a Microsoft MVP and works for one of the leading companies (and Gold Partner) for Microsoft technologies.
However very often MVVM Light is considered to be too “light” to handle complex apps: it is surely something more than the simple few classes automatically provided by Visual Studio in the common directory, but it is not a really framework. We can say that it is versatile and standard, but it requests more work to handle all the scenarios typical of the WP platform (e.g. navigation, life cycle).

On the contrary, both Caliburn Micro and Prism are more advanced and provide helpers for handling all common scenarios, like navigation, status handling etc … Therefore they have much more relevant helping tools for implementing even very complex apps: Inversion of Control (IoC)/Dependency Injection (DI) – see this link if these terms are new for you – , View/ViewModel binding, Messaging (event aggregation), Application Lifetime Management (ALM).

In particular, Caliburn Micro is developed and supported by Rob Eisenberg, Thomas Ibel and Nigel Sampson among others. It was a CodePlex hosted project till April 2014 when it moved to GitHub since v2.0 (it is available also from NuGet): here you can find all the needed information about the framework, the sources, the documentation and the project site. For support, there is a specific caliburn.micro tag in the StackOverflow forum (moreover, there is still a discussion tab in Codeplex that could be eventually also used: even though it is not supported any more from the project authors – they answer only questions posted in StackOverflow – there is still a community behind …). It uses a conventional approach: therefore it is more difficult to understand at first in respect to MVVM Light, but it offers al lot of services already available to handle more commons use cases. Biggest difference is that Caliburn uses naming convention while MVVM Light doesn’t. Using naming conventions makes you fast but it also raises the barrier if someone, not familiar with the pattern, is looking at your code.
Many complex business app are developed with this framework (e.g. Sky app, finance app with very complex UI and navigation).

Prism is a CodePlex project developed by the Patterns & Practices Microsoft division (Microsoft is in fact a project member) and it is very well documented and there are several video tutorials on Channel 9 and in the Microsoft Virtual Academy. At a first look (I am still studying it) it seems to me even more complete than Caliburn Micro but even more complex too, even thought it less uses conventions and so may be some code can be more understandable for beginners of the framework.
Prism.StoreApp (the basic framework namespace) can optionally be complemented by both Prism.PubSubEvents for handling Messaging and by Unity for handling Dependency Injection a lightweight, extensible dependency injection container with optional support for instance and type interception.
It provides really good modern development practices. You will get suitable navigation service, app lifecycle management, great MVVM support and very flexible view and ViewModels resolution mechanism. You can easily add it to your project via NuGet. It has pretty good documentation, so if you have any questions you can find an answer on MSDN or even download free book Prism for the Windows Runtime.

An other possible option could be to use the classes that AppStudio create in order to implement the Model-View-ViewModel pattern: in fact, all the projects visually created with AppStudio (and then downloaded, in order to possibly modify the generated code) implement the MVVM pattern without using a specific toolkit or framework, but with custom classes that are built in the project itself. However, any AppStudio project makes use of Unity (which is an open source project by Microsoft) to support dependency injection … and then it is not clear to me why they do not use also Prism, that is the open source project by Microsoft implementing a framework to support the MVVM pattern (note that, very often, project using Prism also use Unity to support dependency injection!). A useful analysis of the AppStudio generated code can be found in the following Matteo Pagani‘s blog post.

======================

Generic link about MVVM pattern

======================

Useful links for MVVM Light:

Building a Universal Application for Windows Phone 8.1 and Windows 8.1 with MVVM Light (Laurent Bugnion)
MVVM Light Toolkit (Codeplex, NuGet, Adding MVVM Light with NuGet)
MVVM Light Part 1 ; MVVM Light Part 2
MVVMLight Hello World in 10 Minutes
MVVM Light Toolkit Fundamentals (pluralsight payment video)
Stackoverflow (Q&A on MVVM)
MVVM Light e Windows Phone (Matteo Pagani):
- MVVM e Windows Phone – Introduzione (1° parte) (7/25/2012)
- MVVM e Windows Phone – Model e ViewModel (2° parte) (7/30/2012)
- MVVM e Windows Phone – La view (3° parte) (8/2/2012)
- MVVM e Windows Phone – Two way binding (4° parte) (8/6/2012)
- MVVM e Windows Phone – I command (5° parte) (8/9/2012)
- MVVM e Windows Phone – Gestire gli eventi tramite Command (6° parte) (8/23/2012)
MVVM Light Toolkit Fundamentals [Laurent Bugnion] (pluralsight payment video)

=====================

Useful links for Caliburn:

Packages
Public website: caliburn-micro.github.io
Official documentation (action parameters)
MVVM Made Easy: an Intro to Caliburn Micro on Windows Phone
Hello world with Caliburn Micro
http://www.qmatteoq.com/blog/search?q=caliburn&searchButton=Go
http://caliburnmicro.com/documentation/windows-phone (WP 8.1 WinRT) http://caliburnmicro.com/documentation/windows-runtime (WP 8 Silverlight)

Examples:

Caliburn Micro – (sample code GitHub) ;
CaliburnMicro-UniversalApp-Demo of Matteo Pagani; MatteoPagani_OneDrive ; examples from qmatteoq – The Caliburn Micro posts series;
Example on chapter 24 of the book “Sviluppare Universal App per Windows e Windows Phone – Con XAML e C#” (Authors : Daniele Bochicchio, Cristian Civera, Marco De Sanctis, Alessio Leoncini, Marco Leoncini, Stefano Mostarda): samples

Forum: Caliburn Micro StackOverflow

======================

Useful links for Prism

Porting of the Prism for Windows Runtime code to Prism for UWP: http://github.com/PrismLibrary/Prism
NuGet Prism.Mvvm; patterns & practices: Prism for the Windows Runtime
Prism Library for Windows Phone;
Windows/Phone 8.1: Prism for the Windows Runtime (Universal)
Prism and Universal Windows app (Matteo Pagani) (all in a word document)
- Prism and Universal Windows app – The basic concepts
- Prism and Universal Windows apps – Binding and commands
- Prism and Universal Windows apps – Advanced commands
- Prism and Universal Windows app – Navigation
- Prism and Universal Windows app – Managing the application’s lifecycle
- Prism and Universal Windows apps – Messages
- Prism and Universal Windows apps – Layout management

Patterns & Practices: Prism for the Windows Runtime (The Prism library and AdventureWorks Shopper RI demonstrate how to create Windows Store apps using C# and XAML for Windows 8.1 and Windows Phone 8.1)

Patterns & Practices: Prism Model-View-ViewModel (MVVM)
Windows Store app samples on prism; Developing apps (XAML)
Getting started using Prism for the Windows Runtime
Prism Universal Apps and AdventureWorks Shopper

A code snippet to quickly write Prism commands (prismcommand.zip (1,11 KB)
XAML Dev’s Favorite Snippet (how to create a “propnote” snippet to create a new property that support XAML data binding, that is with a set supporting INotifyPropertyChanged).
Windows Runtime Prism Templates for Windows 8.1 (from David Britch Blog)

The following book is a PDF version of the on-line guidance “Developing a Windows Store business app using C#, XAML, and Prism for the Windows Runtime“ [Note – there are two PDF files associated with this download (one version supports Windows 8.1 and the other supports Windows 8)]: