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?
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.
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 is the GUI logic that presents the data on screen. If there is no
View knows about the
Model and talks directly to the
Model. If there is a
View does not know about the
Model and talks to the
Presenter instead of 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
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.