I have some questions about MVVM pattern

Question

My name is Jesús from Spain, I'm a .NET developer and I just discovered this great web few days ago.

I have some questions about the MVVM pattern and I will be glad if you can answer them.
I started using WPF three months ago and I've learned the MVP pattern.
MVP is so good because you can structure the application so well.

I started seeing MVVM everywhere, but everyone is using the pattern by his own method.
Every blogger is talking about MVVM in their WPF's blogs but every implementation is distinct.

I'm focused now with the implementations that use the MVVM toolkit on CodePlex, but I have questions and I can't find too much information.

I think that MVVM is a variation of MVP.
With MVP every view has a presenter that does the view's job.
In MVVM it's the same thing but using commands whenever you can.

I also saw that if you need an event, it's like with MVP; delegating the event to the presenter / View-Model, that is if it's not a job for the view (such as updating the UI).

On the other hand, the View-Model doesn't has a View reference so I have to play harder with data-bindings.
You have to use the DelegateCommands (that are the same thing as RelayCommands, right?).

Uhm... more questions... Is it safe to use the same View-Model with two views / user-controls?

Oh... I ran into a problem yesterday when I was playing MVVM.
I created a CommandReference of my command for the key-binding thing and I assigned this reference to the command property of my button, well, the CanExecuted worked the first time but it didn't update the IsEnabled property when the CanExecuted was true. I fixed it by binding the command directly to the button and not using the reference. The question is: Why some code is linking the reference to the objects and why other code is binding the command directly?

What things related with MVVM should I learn? (I saw something called attached behaviors yesterday but I don't know what is that).

I'm rewriting a note tacking app that I developed using MVP but now with the MVVM. I will replace the events with commands (using the DelegateCommand), eliminate the views references on the View-Model and I think that's all because the examples that I saw of MVVM is much like MVP.

Well, I will appreciate if you point me to all the misunderstandings that I have with this pattern.

Thank you and in the future I will help the next MVVM novices :)

Answer 1

You don't actually have to use the RelayCommand. All you really need to do is implement the ICommand interface on an object. In the SoapBox Core framework I defined an interface called ICommandControl and all button ViewModels, etc. implement that. There's also an AbstractCommandControl class you can derive from to implement it.

Answer 2

Wow, I'm going to try to answer as many of your questions, that don't involve a specific technology or framework, as possible... sorry if I miss some (bullet points would help)

• MVVM is not necessarily a variation of MVP. MVP itself is an ambiguous, loaded term. Martin Fowler did it justice by splitting it into two patterns. MVVM stands on its own, but shares some concepts with the MVP patterns. Like all UI patterns, it seeks to separate view logic from business logic as much as possible. What the MVVM does that is different from MVP is it creates a model purely for the purpose of presentation (or a presentation model). This is different than how MVP patterns solve the separation problem.
  • Passive View - With the passive view, the view never sees the model.
  • Supervising Controller - MVVM is much closer to the Supervising Controller pattern than to the Passive View. The only real difference here could be that the MVVM explicitly creates a model just for the view (hence the term "View Model")
• The ViewModel doesn't have a reference to the view, because it serves as a model for the data of the view. This is an appropriate abstraction. If it also referenced the view, you would have a two-way dependency which would create additional coupling. Also, the ViewModel itself doesn't have a real reason to be aware of the View. Its only job is to abstract the model (the actual business model) from the view.
• DelegateCommands vs. RelayCommands - I believe you're getting technology specific here, so I can't really answer that one well.
• You should not design a ViewModel for more than one view. This only creates coplexity inasmuch as if you change a view, you will have to investigate which ViewModels might be affected and change those. This could possibly lead to a cascade effect. Your behavior should be in the business model, not the ViewModel, so the ViewModel need only contain translation and event handling logic.
• It would be a good idea, however, to have a 1:1 ratio of ViewModel to UserControl, since UserControls are supposed to be able to act as autonomous units on your screen.
• As for the other technology specific questions, sorry, I have no answer. I can suggest, however, that you carefully read the links I included for the Passive View, Supervising Controller, and Presentation Model. The provide some context to UI patterns, and are technology neutral.

It's important to keep in mind that, while MVVM is suited to solving problems posed by adopting WPF, it is not a technology specific pattern. If you dive too deeply into a specific implementation without understanding the underlying philosophy, you could make some very big mistakes early on, and only discover them after it's too late. Unfortunately, MVVM is not a well documented pattern, and you are right when you stated that everyone has their own idea of what it is.

It's not a revolutionary pattern (it has been around for years under different names), but the data binding of WPF makes it a viable solution now, and so it's enjoying newfound popularity. It's a good pattern, but it's not doctrine. Approach every "dictate" you're faced with with the appropriate amount of skepticism.

EDIT

@micahtan is right when stating that data bind is a very important piece in WPF. I stated that WPF's data binding enables the MVVM solution, but the binding itself is very powerful, which is why adoption of MVVM is growing faster than the literature surrounding it.