WPF: MVP vs MVVM

Question

What is the difference between MVP VS MVVM? Why we are using MVP even though we have three layers: business, data access and presentation? Is there any specific reason to divide the Presentation layer into MVP?

Answer 1

MVP and MVVM are both derivatives of MVC. MVC is a pattern that separates the user presentation and interaction from the internal representation.

This requires three layers, since tying the user interaction/presentation directly to the internal representation will cause both to bend to conform to each other. In your application, you described these layers as the Presentation, the Business layer, and the Data Access layer. With only those very loose descriptions, you could potentially be describing any of the MVC derivatives, or the original MVC pattern itself.

The key differences between each of the derivatives are the dependencies each layer takes on the other layers, and how tightly they are bound to each other. This article has some details on the differences, though of course it shouldn't be considered authoritative:

http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/

"... MVVM is attractive for platforms which support bi-directional binding with less effort. Also a minor tradeoff is ViewModel unlike Presenter can stand on its own (Presenter normally requires a View’s interface)."

Answer 2

We use at our company projects of WPF desktop application MVP instead of the built in MVVM for the main reason that in MVP the presenter is the main entry point that knows everything and no one knows about the presenter. For each View the presenter which have one responsibility which is taking interactions from the IView interfaces by subscribing to events that the View triggers.

The presenter updates the View by a properties that encapsulates the internal View controls like TextBox with string properity and GridView with any Collection property.
The constructor of the MainPresenter class will look something like this MainPresenter(IMainView, IEmployeeStore, IOtherDependency,..)
The Constructor of MainView class will look like this MainView(IPartialViewIfExists,..) that means the view does not know anything about the Presenter or anything else outside the View layer (which is the opposite of MVVM that enforces the MainView to directly couple the MainViewModel to automate the two way databinding).

That clean loosely coupling architecture which the MVP provides is really powerful and flexible which enables the ability for the following:

1. Your application can replace the GUI with anytime without changing anything in the presenter, you can also change the GUI technology to something else like WinForms or something.
2. You can separate your GUIs in a separate project that doesn't require any dependencies of your main application like the presenters and dataAccesses
3. Your View can be used for any other application witch is useful for general GUIs.
4. You can unit test the views, the presenters and the data access classes easily.

The ViewModel in MVVM doesn't know about the View but I don't think that is helpful since it is responsible for the View. The View shouldn't know about the presenter which handles business logic and that's what exactly the MVP provides (or the way that we implement MVP).

That doesn't mean that MVVM is bad. MVVM is a good architecture and faster to code and easier to start with since it is already implemented in WPF and Xamarin but as I explained we prefer MVP for listed reasons.

In general MVP is cleaner and more scalable but requires more knowledge and coding experience and have to be implemented manually. MVVM is already there, it is easy to use and lets you implement faster but provides coupling and has some limitations. They all have their pros and cons and it depends on your need.