I have some questions about MVVM pattern

Question

Hello, 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 MVVM pattern and I will be glad if you can answer they.

I started WPF 3 months ago and I learned the MVP pattern. MVP is so good because you can structure the app so well.

I started seeing the mvvm pattern 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 don't find too much information.

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

also that if you need and event, is like MVP, delegating the event to the presenter / viewmodel if it is not a view job (like updating the UI or something).

On the other hand, the ViewModel doesn't has a View reference so I have to play harder with databindings. You have to use the DelegateCommands (that are the same thing as

RelayCommands, right?).

Uhm... more questions... It's safe to use the same ViewModel with two views / usercontrols?

Oh... I ran into a problem yesterday when I was playing with MVVM pattern. I created a CommandReference of my command for the keybinding thing and I asigned this reference

to the command proprerty 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

binding the command directly to the button and not using the reference. The question is: Why some code is linking the reference to the objets 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 (and the mvvm template). I will replace the events with commands (using the

DelegateCommand), eliminate the views references on the ViewModel and I think that's all because the examples that I saw of MVVM is much like MVP.

Well, I will apreciate 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

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.

Answer 2

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.