MVP vs MVVM : a fast introduction
•Télécharger en tant que PPTX, PDF•
0 j'aime•150 vues
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.
Recommandé
Contenu connexe
Similaire à MVP vs MVVM : a fast introduction
Similaire à MVP vs MVVM : a fast introduction (20)
Dernier
Dernier (20)
MVP vs MVVM : a fast introduction
- 1. Nome Speaker@twitter MVP vs MVVM a fast introduction
- 2. ● We are talking 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 View Presenter MVVM: Model View ViewModel
- 4. Model ● This is the 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 ● The view 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 updates the 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 leaves to 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
Notes de l'éditeur
- Presenter and ViewModel hold presentation behavior
- act as a proxy
- Supervising Controller or Passive View
- 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.