UI abstractions, part 1: MVC
MVC
The model-view-controller pattern in short:
Rendering graph...
The model:
- has it’s state manipulated by the controller
- notifies the view about state changes
The view:
- is interactive by
- displaying interactive elements for triggering manipulations of the model
- translating UI-events by then invoking methods offered by the controller
- is rendering the model state by
- having dedicated UI elements displaying aspects of the model state
- listening for change events of the model, updating the UI elements
The controller:
- provides functions for updating the model, which are invoked by the view
Characteristics
It’s possible to realize the MVC-pattern as a ‘one-way communication scheme only’, simplifying control and data flows in the involved components:
- the view either doesn’t know about the model at all, it’s basically just being notified when state changes, so it can update some UI-elements for presenting the new state to the user
- the controller doesn’t know about the view, it only provides functions in order to change the values in the model depending on some business logic
- the model doesn’t know about the view or controller, it just experiences it’s state to be modified externally, and notifies subscribers about those changes
The strict separation in one-way-communication allows the pattern to be easily used in server-side-rendering, in which the view (HTML-pages) display the current state, holding clickable links which, when being clicked, executing controller-logic on the server side, which then update the model, like session information or database state, or even simply embed all model state in the HTML-page, so the server side is completely stateless, and finally, render the updated state into a new view in shape of a rendered HTML page, representing the new, updated view.
In ASP.NET, for example, the controller on the server-side returns the next view to be displayed, after updating the model and rendering the new state via view into HTML.