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.
6
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:
- Data Binding
- Testing
- 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