I am defining the architecture for an embedded system provided with an LCD touch screen for interacting with the user. To describe my problem I can use a washing machine provided with LCD touch screen as an example for my system.
Some of the user actions on the LCD are merely parameters change, like washing temperature, cycle type, etc. Other user actions on the LCD results in the triggering of a particular action. For example, pressing the start button triggers the beginning of the washing cycle.
In the process of defining the software architecture, I am evaluating the possibility to use the MVP pattern for implementing the interaction between the touch LCD screen and the washing cycle. Under this assumption, the View is represented by the touch LCD screen populated with various graphical widgets.
What is not clear to me is how to map Presenter and Model to my particular circumstances.
From my understanding, the model comprehends both behaviour and data. If this is correct, I believe that in my case the Model should be mapped to both washing cycle data and washing cycle logic. Whereas the Present role should be to coordinate LCD touch screen event, such as “Start button pressed”, with the Model.
Is my interpretation correct?
1
Yes, your interpretation is correct.
In the MVP patterns, the View is responsible for the (LCD) display, the Model for the actual washing machine and the Presentation layer is responsible for connecting the two together.
This means that the Presentation layer should
- retrieve the current values of the parameters for displaying them in the view
- update the values of parameters if the user has changed them
- translate button presses on the UI into an action for the washing machine.
To quote from this answer:
ViewModelPresenter projects the data from the Model into a
format that fits the View.
The Model is the data in a way that makes sense to store the data. The Model knows the current washing state, has the ability to start/stop washing, can open the door, etc. The Model is also deciding when it will refuse to open the door. The Model doesn’t know anything at all about the existence of a View or Presenter.
The View is the GUI logic that presents the data on screen. If there is no Presenter, the View knows about the Model and talks directly to the Model. If there is a Presenter, the View does not know about the Model and talks to the Presenter instead of the Model.
The Presenter is the translation layer which allows you to keep the View simple. The Presenter, just like the Model, does not know about the View. The Presenter is not strictly necessary: If the Model presents the data in a format that is trivial to display by the View, there is no need for a translation between them. But in real world projects there almost always comes a point where you do need a Presenter, because either the Model or the View change from the original design, making the originally trivial translation non-trivial.