Model-View-ViewModel (MVVM) is a client-side design pattern. It guides the structure and design of your code to help you achieve “Separation of Concerns.”  Implementing MVVM requires a bit of a mind-shift in the way you think about the functionality of your application. It has a significant learning curve and requires some additional upfront effort to get started on the right path. But the benefits are significant:

  • Your code is easier to understand, maintain and troubleshoot.
  • You are much more productive when you leverage the frameworks’ (WPF, Silverlight, XAML, WinRT) built-in features like Data Binding, Resource Dictionaries, Dependency Properties, Routed Events, Commands, etc.
  • You can test your app’s behavior “under-the-skin,” avoiding the pitfalls and cost of testing at the UI level.
  • Your ViewModels afford testability. You can have unit test coverage allowing “Test-Driven-Development” and “Automated Regressions.”
  • Decoupling the View from the ViewModel in the way enabled by MVVM allows designers and developers to work productively in harmony.

[pullquote]If you want your Windows Phone App and Windows Store App to be also available on Android, iPhone and iPad, you will be able to reuse a significant portion of your effort when developing on those other platforms if your app is structured as an MVVM app.[/pullquote]I sense, from my conversations and interactions with developers in code-camps and user-groups over many years, that these potentially significant advantages are not enough of a motivation for many developers to make the switch to MVVM. There is also a perception that implementing MVVM is overkill for a “small” app. MVVM is perceived to be too heavyweight and not worth the effort for many Windows Phone Apps, Windows Store Apps and development prototypes. This is a view shared by many and I understand and sympathize with this perception. However, I am proposing that we use MVVM for all applications, however small and seemingly insignificant. My proposal is based on two realizations:

  1. Inserting the learning curve of MVVM in the critical path of a large project is counterproductive, in my opinion. Using MVVM in small apps and prototypes is the best way to understand and experience the MVVM development style and thinking.
  2. There is a brand-new reason for C# developers to start “thinking in MVVM.” Structuring your C# and XAML code as MVVM and separating your classes as Models, ViewModels, Views, Services, DataAccess and such will give you a head start in reusing a lot of your code on other platforms like Android and iOS. Think about this for a moment – if you want your small Windows Phone App and Windows Store App to be available on Android, iPhone and iPad, you will be able to reuse a significant portion of your effort when developing on those other platforms if your app is structured as an MVVM app. The potential increase in the reach, customer base and revenue is enough for a lot of developers to reconsider the effort to achieve the separation of concerns enabled by MVVM.

Reusing C# code to create apps for Android and iOS is made possible by Xamarin. The level of code reuse depends on the level of separation-of-concerns that you achieve in your application. The Models, Services and Data Access code is reusable with little effort through Xamarin’s absolutely fantastic ability to create native Android and iOS apps using C# code. It is possible, by using MVVMCross, to take code reuse to another level by reusing your ViewModels also. Stay tuned for more about these techniques and technologies on this blog. In the meantime, whet your appetite by reviewing these resources:

AIS has invested heavily in early adoption and technical readiness for designing and building browser-based and native applications for mobile, touch-enabled devices. See examples of our work here, and read more about our full range of mobile-related offerings here.