prism vs mvvm light for UWP application

Question

We have a working project in Windows 8.1 which is made compatible to Win 10. Now the requirement is to convert this project to UWP. In the earlier project, we have used PRISM as the framework for MVVM. Now the problem is that for UWP application, the new version for Prism is not yet released and we are considering to use MVVMLight.

I am new to both these frameworks, ie, PRISM and MVVMLight. Now my question is how difficult will it be to move the codebase from PRISM to MVVMLight. If it will be difficult, should be wait for PRISM newer version to be released. And if we should move to MVVMLight, what major changes need to be done.

According to my observation, the codebase is highly coupled with PRISM where there is extensive use of interfaces like IResourceLoader, ISessionStateService and so on throughout the code. Also, I read that PRISM has a learning curve while MVVMLight does not. So if we do decide to move to MVVMLight, will I have to learn PRISM first to understand the codebase and then learn MVVMLight to port the codebase. If we decide to wait for newer version of PRISM to be released which is sometime this week, will there be major code changes?

How is Unit Testing supported with respect to both framework.

Since, there is not much time allotted for this task, which will be most efficient way to go ahead with?

Schiller

"the codebase is highly coupled with PRISM" - I think this is your biggest problem here. – Ramillies

Okay. So could you please descibe a little about what efforts will be required to move to MVVMLight as we are not getting sign off for using PRISM yet. And I did say, new to both the frameworks. – Schiller

You don't need a fancy framework to make MVVM work for you, it just makes some things a little easier to achieve, like Dependency Injection for example. The holy grail is to allow your code to be adaptive to change, separating layers and exposing implementations as interfaces. Using a fancy framework will more than likely tie you to that framework unless you can find a way to segregate the dependencies. This is a pretty massive topic, but I would recommend reading up on adaptive code. – Ramillies

Thanks Mike. I would read that book. You wrote - "Using a fancy framework will more than likely tie you to that framework unless you can find a way to segregate the dependencies." So are you suggesting that I dnt use any of the above two mentioned frameworks? – Schiller

"So are you suggesting that I dnt use any of the above two mentioned frameworks?" - Not at all, however you should not feel obliged to, and it should be completely optional, hence the need for adaptive code. Currently, your project relies on PRISM, there's nothing stopping you from migrating to a different framework other than the code that you already have in place. Assuming you don't have any deadlines, you are in the perfect position to refactor your code to help cope with these kinds of changes. If I were you I would spend some time trying to separate your code from the PRISM dependency. – Ramillies

Although @MikeEason is correct by stating it's best to decouple as much code as possible, you have to know that selecting PRISM came with some advantages over MVVM light. Because it contains code that you don't need to write yourself anymore. One example is the ViewModel data saving to local storage when navigating. So if you want to move on to another framework you'll need to rewrite baked in functionality... – Cauthen

It is worth noting that Prism 6.0 for UWP applications has been released since the time this question was asked. – Capwell

Also worth noting that a course on Channel9 uses Prism for UWP apps. channel9.msdn.com/Series/… – Nader

Answer 1

TL;DR: Compile the latest Prism code in anticipation of the new NuGet packages.

First of all a small intro on Prism to get everybody on the same foot. Prism is a MVVM guidance/framework created by Microsoft Patterns & Practices. They released up to version 5 for WPF/Silverlight. Next to that they also released Prism for Windows Runtime for Windows 8 and later updated to Win8.1/WP8.1 RT. These are 2 different codebases with the second one being more lightweight in the aspect of regions etc, but giving very useful support for application lifecycle management. It's a common misconception to think they're the same.

In March, ownership of Prism was transferred to the community as an open source project and is available on GitHub. They decided to move forward, merge the common code in a PCL core assemby and add support for Xamarin Forms.

As of today there is no RTM release of Prism 6 for UWP yet. The codebase is pretty close to be released with only a few minor issues open, but nothing major preventing most users to use the bits already. At this point of time I would tell you to clone the GitHub repository, compile the assemblies and start porting your app. There are a few breaking changes (mainly namespaces), but you should be up and running in no time. Once the RTM packages are available, drop the hard references and use NuGet.

I have already ported one of our smaller apps and I'm planning to port one of the larger LOB ones (over 60 screens) this weekend.

---

To come back to the discussion which MVVM framework to use. If you have an app of just a few pages, don't bother using a framework and keep your MVVM simple. If you're going for complex LOB apps, these frameworks have their advantages (and of course disadvantages). There are plenty of choices (MVVM Light, Prism, Caliburn Micro, ...) and all of them are good.

The fact that your colleagues choose for Prism might have a reason like Depechie mentioned. In first place I'm thinking about application lifecycle management where Prism has far superior support for.

With a correct use of base classes you should be able to refactor away most of the dependencies from every single ViewModel in case you want to switch to another framework after all.

The major differences (on top of my head) between Prism for Windows Runtime and MVVM Light that you will have to tackle when switching are VisualStateAwarePages, ViewModelLocator (auto vs property for each view), BindableBase for INotifyPropertyChanged and everything about application lifecycle management. Both frameworks are good, but I wouldn't recommend switching a full blown LOB application between them as it's just too much work (introducing possible bugs).

Adult

Thanks Bart. I have one QQ, Is Prism 6.0 is just migration of code with new namespace and support of base libraries of UWP ?. Does it also supports all the controls of UWP like adaptive triggers, relative panels etc with new prism 6.0? – Schiller

Controls (e.g. Relative panels) and adaptive triggers is purely UI matter. That is something you normally don't deal with in your MVVM framework unless you want data to go back to your model via binding / command / behavior. – Adult

Answer 2

Windows 10 UWP apps are far less suitable to any of the frameworks you mention. Their rich navigational capabilities and adaptive layouts means that it's hard to see how Prism would work well for you. As regards to MVVMLight, it offers very little above you rolling your own viewmodels, and by avoiding it you can dodge the possibility of a nasty lock-in that will bite you later (which it often does)

Myers