We work in a Java shop here and our web application uses an implementation of the MVP architectural pattern. Our manager comes from a .NET world, where he has been exposed to the MVVM design pattern. Our manager is advocating changes in our MVP implementation, including that the Presenters should be decoupled from (or loosely coupled to, depending on your interpretation) its Views via the Observer design pattern, in tradition with MVVM. I am more of the opinion that the Presenter and the View work together to achieve a common goal, and as such should be coupled.

Among the arguments brought up in support of the change is the ability to unit test Presenters. If the Presenters only see the views as Observers, the argument goes, then they can be more easily unit tested. But presenters strongly coupled to their views are not necessarily difficult to test. If the View uses the Humble View paradigm, then it can be mocked. And finally, testability should be a symptom of good design, not a driver for the design.

Another argument used by my manager in support of layering the Views and the Presenters is the supposed maturity of MVVM. As such, we should follow MVVM's teachings and adapt to its implementation of MVP. Correct me if I'm wrong, but MVVM imposes the (artificial) layering of views and presenters in order to facilitate its data bindings in controls.

Can you please help us see the light here? Why should we use a decoupled model and pay the price for it? I'm not seeing the benefit. Occam's razor says I need arguments to use decoupling, and testing doesn't seem to be one of them.

Clarification: What I'm really looking for with this question are the arguments that can tip the balance in favor of a presenter that doesn't know about its view and shoots events in the aether or in favor of a presenter that knows about its view(s) through more direct coupling, like a humble view interface or directly to the class. Note that presenters can easily serve multiple views with both loose and tight coupling. The difference is in the interface that the presenter talks to: with loose coupling, the presenter talks to listener classes (or an event bus representative), whereas with tight coupling, the presenter talks to the view interface.

  • I don't know, but I thought the question was very well written :-) – Lyn Headley Jan 16 '14 at 22:52
  • Does your framework support MVVM? If not then what is his proposal? Write your own MVVM framrwork? Also are you web? – Gus Jan 27 '14 at 19:14
  • @Gus: yes, this is a web application, using an inhouse MVP on top of Vaadin. No MVVM here, no. The suggestion is that we adjust our MVP; one way is for the presenter to send data to the view only through events, exactly like the ViewModel in MVVM. – Mihai Danila Jan 28 '14 at 19:33
  • I haven't used Vaadin, but from their website it looks like an abstraction over the whole browser/server interaction? Is that a fair statement? In my experience MVP type patterns work well for server side rendering while MV* type patterns work well when the rendering is done on the client. – Gus Jan 29 '14 at 15:17
  • 2
    Do you use data binding? My view is that MVVM is driven by data binding (a core .NET feature) and the benefits in the absence of data binding are very limited. – david.pfx Apr 22 '14 at 4:39

I apologize to be the one to tip the argument against you. You are right, one strength of MVVM is it's ability (if implemented correctly) that you do not have to manually synchronize your data.

I would also have to agree with the testing being easier with MVVM.

For more arguments against or for, I would have to say that another strength of MVVM is that you can have more than one View Model for multiple Views.

So top three reasons for MVVM over MVP I would have to say is:

  1. Data Binding
  2. Testing
  3. Multiple Views can use more than one View Model - Meaning you don't have to create a Presenter for every view.

After that the benefits become minor, and I feel that comfortability in the design you are using would out weigh those benefits. However, It is good to stretch and spread out into uncomfortable areas of design and programming, it broadens your horizons.

  • Regarding #1, can we not use data binding with classic MVP? Could you elaborate on #3? Can't we have a many-to-one between view and presenter in MVP? Regarding #2, I'm trying to understand what gives you that extra testability. Certainly whether you can test the UI controls is orthogonal to your choice of MVP or MVVM. Why couldn't we test everything but the UI controls if we elect MVP, effectively achieving the same level of testability as MVVM? – Mihai Danila Apr 23 '14 at 4:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.