I was using MVP when I was working with WinForm. But I moved to MVVM when I started playing with WPF or Silverlight.
The only thing that I noticed is that we don't need to sync with the data between View and ViewModel in MVVM pattern because of powerful binding.
My questions are:
1) Is Binding (that helps us not to sync View and ViewModel manually) the only advantage of using MVVM?
2) Is there any other advantage MVVM over MVP? What are the differences?
3) The code below is MVVP pattern or MVVM or both?
interface IView {
void ShowMessage(string message);
}
class View : IView {
public void ShowMessage(string message){
MessageBox.Show(this, message);
}
}
class ViewModel{
private IView view;
public ViewModel(IVew view){
this.view = view;
}
........
view.ShowMessage("This is a msg");
}
Answer
I realize that your question has been asked two years ago but I would like to give my input after working with MVVM for over one year now.
-1- I'm not sure what you're asking but I think you're asking: Is binding the only advantage to MVVM? The answer is no. Separation of concerns, binding, and efficient testing are major benefits to MVVM. There are many minor benefits but I won't get into those. Binding is absolutely wonderful because all syncing is automated which means less work for you. Also, separation of concerns means that the view model is not dependent on the type of view so you can have multiple views using the same view model. Let's say for example that you create a view model called ErrorDataViewModel. The purpose of this class is to hold a list of ErrorType classes that will be displayed to the user. The ErrorType basically shows error information. The ErrorDataViewModel also has a boolean property called AllErrorsFixed that lets the user know whether all errors in the list have been fixed. AllErrorsFixed is a simple property that uses linq to query the list of ErrorTypes.Fixed property. If All are fixed, AllErrorsFixed will return true.
In Application1, your customer wants errors displayed in a simple grid-like fashion. All you do is bind a grid to that view model's list of errors. In Application2, your customer wants the errors displayed in more of a navigational format where they can view each error form by form. All you do then is bind your form control to each error in the list and setup your navigation to move from one record to the other. But wait, if we want App1 to utilize both a grid and form-by-form navigation, we can do that. Even better, now you desire to implement a web interface using Silverlight to either replace Application1/Application2 or as another product offering, you do not have to change the view model. Work is done.
I mentioned the ErrorsFixed boolean value, well, we forgot to implement that in our applications. All I have to do is go into my views, add a control or a column or a property tester and bind it to the boolean property and you're finished.
In regards to testing, testing can be more efficient because you can write test code to validate changes within the viewmodel without wasting time running the apps and opening the views. This doesn't solve all testing issues but it eliminates many time consuming steps.
-2- Is there any advantage to MVVM or MVP. Yes. One poster was incorrect in saying that one view can have multiple VM's in MVVM. Actually, one VM can have multiple views because it isn't tied to a view. Or said another way, multiple views can utilize one VM. So, in your example where you call view.ShowMessage(), this would not happen in MVVM because you can't guarantee that the view (WPF or Silverlight or test class) has a ShowMessage method. Instead, you fire an event. In fact, Prism is awesome with this because it has event aggregators so when you fire an event, the event aggregator handles sending the event to the View that's assigned to the event. Therefore, each app's view can handle the event how it sees fit. With MVP, you have to create a Presenter for every view. This is extremely time consuming.
-3- Your example code is MVP.