How reusable should ViewModel classes be?

Question

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?

Gallows

This is an old question, but the answer from MSDN is very clear (and contrary to all the answers posted below): The ViewModel is very specifically intended to be shared by many views across various OSs. Doing otherwise would inevitably lead to redundant code. – Siple

Answer 1

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.

Ja

Answer 2

This is an old question, so I hesitate to add another answer. But all the answers posted so far have missed the point. The answer from MSDN is very clear: The ViewModel is very specifically intended to be shared by many views across various OSs, as demonstrated in this figure:

Doing otherwise would inevitably lead to redundant code.

Siple

Answer 3

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.

Chasidychasing

Answer 4

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.

Scolopendrid