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 :-) Commented Jan 16, 2014 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
    Commented Jan 27, 2014 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. Commented Jan 28, 2014 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
    Commented Jan 29, 2014 at 15:17
  • 3
    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
    Commented Apr 22, 2014 at 4:39

3 Answers 3


Occam's razor says I need arguments to use decoupling, and testing doesn't seem to be one of them.

Why should we use a decoupled model and pay the price for it?

MVVM imposes the (artificial) layering of views and presenters

I'm with you on all of these points. If there is no immediate benefit that you can see, there's no point adding complexity.

Curiously I use the same arguments against MVP, MVC and all its ilk. Its all "artificial" as you say. Unless I see an immediate benefit, helps to solve problems or fulfill requirements, I'm not using them. According to Occam, KISS, etc., the default should be the "business" object emitting a presentable object of some sort that is already wired up as necessary. This may be a static string with HTML if that is enough for the requirements, or could be a complicated component object, it doesn't really matter.


The real key is to separate logic from effects. IMO, this is the primary goal of any architectural pattern. Both MVP and MVVM (if done right) do a decent job of enforcing this separation.

As long as you have a system to enforce this separation that is consistently used, then your architecture is good as far as I'm concerned.

Once that primary goal is met, the next question is, how easy is it to be consistent? When comparing two architectures that are both successfully keeping logic and effects separate, the better architecture is the one that requires the least boilerplate.

By "boilerplate" I am explicitly calling out the requirement of creating test doubles in unit tests. If you need to create a test double in order to unit test your logic, it means you have injected effects into your logic, that now must be mocked out in order to test said logic. Ideally, that won't be necessary and the architecture that requires fewer test doubles when unit testing logic is better by this view.

Now there are lot of variations of both the MVP and MVVM pattern and you haven't specified exactly how you have or plan to implement the two architectures, so I won't call out either as being better or worse. But if I were looking at your code, the above two criteria would be what I use to "tip the balance."

Can I (1) test the logic in the system without tripping effects and (2) do so without creating a bunch of test doubles (mocks, fakes and stubs) in the process?


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.

  • 1
    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? Commented Apr 23, 2014 at 4:40

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