Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How reusable should ViewModel classes be?

I'm working on a WPF application, and I'm structuring it using the MVVM pattern. Initially I had an idea that the ViewModels should be reusable, but now I'm not too sure anymore.

  • Should I be able to reuse my ViewModels if I need similar functionality for a WinForms application?
  • Silverlight doesn't support all things WPF does - should I be able to reuse for Silverlight applications?
  • What if I want to make a Linux GUI for my application. Then I need the ViewModel to build in Mono - is this something I should strive for?
  • And so on..

So; should one write ViewModel classes with one specific View in mind, or think of reusability?

like image 221
stiank81 Avatar asked Mar 15 '10 12:03

stiank81


People also ask

Should ViewModel know about model?

Models are just the plain data, and a ViewModel is something that acts like a padding in between the two, that it should get information from the Model and pass it onto the View, and the View should know how to present it.

Can ViewModel contain other ViewModels?

It is perfectly right to have ViewModel contains ViewModel. Actually that is the recommended practice: To have one main ViewModel for the whole page, the main ViewModel could contain ViewModels for the sub views in the page.

What is the purpose of ViewModel?

The purpose of the ViewModel is to acquire and keep the information that is necessary for an Activity or a Fragment. The Activity or the Fragment should be able to observe changes in the ViewModel. ViewModels usually expose this information via LiveData or Android Data Binding.


3 Answers

To answer your question, think about Single Responsibility Principle:

"A class should have one, and only one, reason to change."

I'd say, within reason, you typically don't want to reuse a ViewModel for multiple views. The main reason I'd argue for this, is because that would give your ViewModel more than one reason to change. In other words, it'd need to change if one or the other view changes, and in my opinion, that's two reasons to change. Where does it stop? I'd keep it simple in this case, and bind one ViewModel to the View.

Another thing to think about with MVVM with WPF is Data Templating. It's much easier to accomplish if each ViewModel caters to one and only one view.

like image 151
David Morton Avatar answered Sep 29 '22 11:09

David Morton


Just in general, apply the YAGNI principl - you probably aren't going to need it. Unless you can see these things as potentially happening, I'd keep with the simplest approach to get your software working for the requirements you currently have.

like image 37
Paddy Avatar answered Sep 29 '22 12:09

Paddy


In my mind, the main goal of MVVM is to eliminate code that cannot be easily tested by unit tests. Since a view model can be unit tested but a view cannot, this is achieved by making the view as dumb as possible. Ideally, as can be done with XAML, the view is completely declarative and only data-binds on a view model. Hence the "no code behind" mantra.

Re-usability of the view model across different UI technologies is not really a goal of MVVM. If you try it you will probably be tempted to move code specific to the UI technology to the view again to keep the view model reusable. This would go against the main goal of testability.

If you really find yourself needing to support different UI technologies, then you could still factor out the common logic of the view models into a shared "presentation" layer. I wouldn't do that until sure that it is necessary though.

like image 29
Wim Coenen Avatar answered Sep 29 '22 13:09

Wim Coenen