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.
Best Answer
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?