MVP vs MVVM - Why?

I was using MVP when I was working with WinForm. But I moved to MVVM when I started pl开发者_JAVA百科aying 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");

}

---

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.

---

The main features of both of them for use in Android environment.

MVP pattern:

• Consists of Model, View, and Presenter layers;

• View delegates user input to Presenter; both of layers should have a 1 to 1 relation;

• View and Model aren’t tightly coupled for clear separation of
  concerns;

• View connects to the Model via data binding directly;

• Easy unit testing, as an interface for Presenter layer one may mock quickly;

MVVM pattern:

Includes three key parts:

• Model (business rule, data access, classes),

• View (user interface),

• ViewModel (as agent between view and model);
• Great solution to handle tasks related to Windows Presentation Foundation system (WPF) and Silverlight application framework;
• Provides clearer separation of the UI and application logic;
• Unit testing even easier, as there is no dependency on the View

Feature comparison

Let’s put together the essentials of MVP vs MVVM to compare. We should also stress that we aren’t advocating for one or pattern.

Code metrics: MVP may produce more classes and Java code. In MVVM there are more Java classes but less code per class.

Maintainability: MVP is easy to learn, amend, add features. Adding new features with MVVM may require some experience with the library.

Logic: in MVP the View is actually your application while Presenter handles the app flow. In MVVM code classes (ViewModel) are the application, while the View is the interface allowing users to interact with the app.

Data input: Begins with the View in MVP, not the Presenter. The input in MVVM begins with the View, not the ViewModel.

Mapping and references: One-to-one mapping between the View and the Presenter in MVP, no reference between them. One-to-many mapping between the View and the ViewModel in MVVM, no reference.

Final words

Evidently, architectural patterns evolve. MVVM has the tendency to become a really neat and apprehensive tool. Meanwhile, MVP pattern is flexible enough already benefiting from various libraries.

What is also clear is that you do not have to stick strictly with MVP or MVVM. In most cases we can not build an app purely on a single pattern, and that’s fine. The main things is to separate the view, the model and the logic between them.

When to use MVP and when to use MVVM, you might ask? The advice hides rather in data-binding. In cases where binding with datacontext is not possible, most developers prefer MVP (Windows Forms being a great example). MVVM is of preference in cases where > binding with datacontext is possible, as there are less interfaces and less code to maintain.

by the materials of the blog.

---

Example is MVP, clearly defined by this line:

view.showMessage("This is a msg");

While code resulting from MVP and MVVM may look similar in trivial examples, those patterns are significantly different. If you suspect that MVVM is just Microsoft's name for MVP, it's not.

It is Microsoft's name for a less known PM (Presentation Model) pattern - you may want to read up its description.

---

One of the most Important difference between the two is that, In MVP, tight coupling is there i.e presenter which is an interface holds the reference to the view, while in MVVM, viewmodel doesn't hold the reference of the view.

second difference is MVP is one to one relation between view and presenter while MVVM is one to many relationships. That means, we can use a single viewmodel with many different views, but in MVP, Presenter is tied to a single view.