MVVM + WPF - Design for ViewModel that has Multiple Views

0
votes

I develop .NET/Winforms applications that runs on various kiosks. These apps are typically full-screen and touch-controlled. Newly I would like to use WPF technology and MVVM design pattern.

Viable design of these applications is that I have one MainForm (Window) that switches screens (UserControls) on it. So you have only one "current" screen with buttons like Previous, Next (like an wizard).

Most of the applications have very similar logic. They eg. need to get OrderNumber (PIN, any text..) from user (one screen), process payment by card (second screen),... What differs accross applications is GUI: images, fonts, colors, monitor resolutions, buttons locations,...

My idea is to write typical ViewModels and put them in common library. Specific applications then would provide their Views for these ViewModels. Every ViewModel will then be bound to one specific View during whole application life.

Example:

Library Common.dll

  • contains typical ViewModels: ScreenGetTextViewModel, ScreenPayByCardViewModel,...
    • (contains also default Views for ViewModels)

Application 1:

  • references Common.dll
  • contains Views for Client 1: ScreenGetTextView, ScreenPayByCardView,... (these views are bound to ViewModels from Common.dll)

Application 2:

  • references Common.dll
  • contains Views for Client 2: ScreenGetTextView, ScreenPayByCardView,... (these views are bound to ViewModels from Common.dll)

MVVM looks to me like the right way to achieve my requirements, because of logic and GUI separation.

My question is how to make this in WPF, what to use, where to inspire myself. I prefer simple solutions without 3rd party MVVM toolkits (if it's reasonable and possible).

Some sub-questions/ideas:

  • How to specify what View should bind to particular ViewModel? Use some ViewLocator? Put "View" property to ViewModel?

  • I prefer write the Common.dll not coupled to WPF because of possible UWP applications in future (if reasonably possible).

Thank You

2
.netwpfmvvmkiosk
Yes it's possible and MVVM is very easy to do w/o a framework. But ViewModels belong to (serve) a View, not the other way around. I think what you describe is a business logic layer, that would makes much more sense to share. – Henk Holterman

2 Answers

0
votes

I've only ever seen one view per ViewModel - so I'd be interested if there's another way to do it.

I'd do this with a ViewModel for each view, but each ViewModel inherits from the common ViewModel.

So Common.dll would contain ScreenPayByCardView, and Application 1 would contain App1ScreenPayByCardView which inherits from ScreenPayByCardView. Possibly this ViewModel might even contain no logic of its own.

0
votes

In an MVVM-scenario you typically reference a viewmodel in the view's XAML code as datacontext. So there is no issue, having two instances of your viewmodel class being invoked by two different views. Using a view locator makes sense, if you like loose coupling for unit testing.

if your common.dll contains only the viewmodels it should not be coupled to your WPF-views. Otherwise you have violated MVVM-pattern.

Being relatively new to MVVM and having had the constraint not to take a framework I still enjoyed Laurent Bugnion's course on MVVMLight on Pluralsight (you might have a free 3 months subscription in your MSDN license): https://www.pluralsight.com/courses/mvvm-light-toolkit-fundamentals

I also often looked into MVVMLight's code to understand certain service implementations: https://github.com/lbugnion/mvvmlight/

For a second project, I would use MVVMLight right away, since it is open sourced. but for a first project it was good to feel the pain and understand why MVVMLight (and other frameworks) take certain turns.

hope that helps!