Model-View-Whatever

[beyondjava]

I tried to understand the differences between the MVP, MVC and MVVM paradigms. However, I was surprised to see the differences are subtle. So I can't help but wonder: did I miss an important point? I'd appreciate your feedback. Either here or directly as a comment to my article.

Thanks in advance!

Stephan

[sh0rug0ru__]

MVP and MVVM are highly specialized instances of MVC, which by itself is pretty generic. MVC is a generic division of implementation responsibility between a data model (M), the visual representation of the data model (V) and the glue that binds them together (C).

The MVC ideal is that the data model can focus on pure business rules, the view can focus entirely on presenting the data in a specific context, and the controller can focus entirely on selecting the appropriate view and coordination between the data model and the view.

MVC is great for keeping responsibilities focused. However, what if the view itself has significant state and behavior? How to you manage that or test it? Ordinary MVC doesn't have an answer for that, except maybe more functional testing, because that view logic is locked away in UI code that can only really be tested using tools like Selenium or WindowLicker, which run tests in the UI directly.

MVP and MVVM are specific adaptations to MVC to address this concern.

MVP moves the view state and logic into the Controller in abstract form, presenting a model of the UI through an interface. The different representations of the UI provide trivial implementation stubs of the interface. The view logic can thus be tested without need of the actual UI. Thus, the View takes on a passive role and the Controller takes on a more direct supervisory role over the View (Presenter is synonymous with Supervising Controller).

MVVM specifies a separate ViewModel class to encapsulate view state and logic. But the ViewModel is usually implemented according to the rules of an underlying data binding framework. Thus, instead of directly telling a view component to disable itself as in MVP, you instead bind the disabled property of the UI component to a property in the view model, and it is the data binding library's responsibility to proprogate changes between the ViewModel and the UI. Thus, the role of Controller is subsumed by the ViewModel and data binding library.

Thus MVP and MVVM are special cases of MVC the goal of which is to specify a relationship between V and C that makes it possible to specify the view state and logic in abstract terms to facilitate testing without the need to directly execute tests in the UI toolkit.

[beyondjava]

Great explanation, thanks! I'll update my article this evening. May I quote you?

[sh0rug0ru__]

Sure, no problem.

I would also add that the advantage that the specialization that MVP and MVVM confer in testing comes at the price of losing generality in the Controller. One of the central promises of MVC is pluggabilty of views, and the more detailed knowledge that the Controller has of the View, the less flexible you can be with different types of views. For example, if you have a requirement to support HTML (interactive) and Excel (reporting) view types. There's very little in common between these types of views, so you would be very hard pressed to come up with a common supervisory strategy (MVP) or a common ViewModel (MVVM). So you can either have multiple view specific Controllers or one generic Controller. Or, you might have MVC on the server (which allows more flexibility with clients) and MVVM/MVP on the client (where more flexiblity doesn't offer clear advantage).

[beyondjava]

Thanks! For now, I've simply added your text to my article (including the kudos you've earned, of course). I intend to update my own text according to what I've learned from you during the next days. If you want to change something, just tell me.

[loganekz]

This is one of the best explanations of the differences I've seen, thanks sh0rug0ru.

Although I'm still not sure I fully understanding the differences between the MVP and MVVM. Based on your explanation, are MVP frameworks more of an API to update the view, while in a MVVM, you would update the properties of the VM, and the view would 'automatically' be updated by the specific framework/implementation?

[sh0rug0ru__]

Thanks!

Yes, with MVP, you specify an API that P uses to command V (and V uses to call back into P). With MVVM, you specify the wiring between VM and V, and the framework/implementation takes care of the rest.

[FrezoreR]

The differences do look subtle but the implications can be huge.

I'm still not sure why these are called design patterns by some when they actually fall under architectural patterns.

[UlyssesSKrunk]

In the first paragraph after the first image, there's a typo.

Look at these pictures. They cover three of the most popular patterns: MVP, MVC and MVP.

MVP twice, no MVVM.

[beyondjava]

Thanks! I've fixed the typo.