Model View Something
Data and views of data: the data model and visualization of the data should be separated.
There may also be derived data and hence the data cannot be used directly; a bridge that connects the model and views (both of which can be reused) must be used.
There are several variations on this:
- Model View Controller
- Model View Adapter
- Model View Presenter
- Model View ViewModel
Which model to use? What ever the framework gives you.
As the data may be updated, it is useful to have a data-binding that updates the view when the data is updated. The binding may be one-way or two-way.
Record state: source-of-truth, possibly a server.
Session state: state in the client; the model. Data is bound to the view (presentation).
Model-View-Controller
- Model updates view
- User input on the view updates controller
- Controller updates model
- The view is stateless and has little logic
Benefits:
- Supports multiple, synchronized views
- Views and controllers are pluggable
Downsides:
- Complexity in large applications
- Couples controller and view
- Mixes platform-dependent/independent code within controller and view
Model-View-Presenter
Presenter is bridge between model and view - no direct communication between the model and view.
e.g. if there is invalid user input, the presenter will put a error message on the view, but not update the model.
Model-View-ViewModel
- ViewModel contains only the data required by the view and mediates communication between the Model and View: this is called the binder
- Model contains business logic and data
- Could be on the server
- Data binding between the View and ViewModel is two-way
- No communication between the View and Model
This is used by Vue.