Download to read offline
Uploaded byMatteo Pierro
MVP vs MVVM : a fast introduction
This document compares the MVP and MVVM patterns for building testable GUI applications. MVP stands for Model-View-Presenter, where the presenter receives user input, updates the model, and handles reloading the view. MVVM stands for Model-View-ViewModel, where the viewmodel acts as an abstraction of the view using data binding and observers. The key differences are that the presenter pulls data from the model to update the view, while the viewmodel provides an interface to the view. Both patterns aim to separate concerns to make the application components more testable.
Softwareā¦
MVP vs MVVM : a fast introduction
- 1. Nome Speaker@twitter MVP vsMVVM a fast introduction
- 2. ā We aretalking about GUIs Why? BECAUSE ITāS HARD TO TEST YOUR GUI ! ā GUIs consist of widgets that contain the state of the GUI screen ā Most rich client frameworks encourage putting presentation behavior in the view class ā Most rich client framework were not build with automated testing in mind
- 3. Acronyms MVP: Model ViewPresenter MVVM: Model View ViewModel
- 4. Model ā This isthe data upon which the user interface will operate. ā Itās purely a domain object and there is no expectation of (or link to) the user interface at all. ā The intention is that such objects should have no knowledge of the user interface. ā You can test it in isolation!
- 5. (Humble) View ā Theview is a humble object: ā any object that is difficult to test should have minimal behavior. ā Reduce the behavior of the UI components to the absolute minimum ā The view is a dumb slave of the controller: ā forwards user events to the controller ā widget updates are pushed by the controller ā Make the view sufficiently humble to help in testing ā you run little risk by not testing the view ā if we are unable to include it in our test suites we minimize the chances of an undetected failure
- 6. ā It updatesthe model, and then handles the reloading of the view. ā Easily testable using test double without needing any interaction with the UI framework MVP - Presenter ā It receives all user events ā the view is a dependency of the Presenter ā data are pulled from the model, and using them to update the widgets
- 7. ā It leavesto the view to synchronize all its updates ā It stores the view state (only the once that can change) MVVM - ViewModel ā It receives all user events ā abstraction of the view that is not dependent on a specific GUI framework ā The view is not a dependency ā It provides an interface to the view ā mainly using the observer pattern and data binding
- 8. References ā https://www.martinfowler.com/eaaDev/uiArchs.html ā https://martinfowler.com/eaaDev/PassiveScreen.html āhttps://martinfowler.com/eaaDev/SupervisingPresenter.html ā https://martinfowler.com/eaaDev/PresentationModel.html ā http://www.object- arts.com/downloads/papers/TwistingTheTriad.PDF
- 9.
Editor's Notes
- #4Ā Presenter and ViewModel hold presentation behavior
- #6Ā act as a proxy
- #7Ā Supervising Controller or Passive View
- #8Ā Presentation Model and Application Model nel mondo Smalltalk The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. There isn't a great deal of the difference in test coverage between Presentation Model and Supervising Controller - much of the choice (as with Passive View) depends on personal judgments.