Model-View-Controller (MVC)

MVC is an #decoupling idiom that separates the model from the view and the controller that manage the view. In this page, the model is defined as the abstract data model, for it to be a variable or #data-structure, that represent the target object which can be from multiple form of sources. View is defines as the user interface, either GUI, TUI or CLI, to the model, which could be nested. In other way, it is the interpretation of the model. Controller is the way or mean to handle the view and sometime could supply the model with new data.

Note: Model should be easy to be parsed and read.

Note: Controller can be a mean to prevent overwhelming information due to the viewers (filtered models) to increase the usability#.

Each model may have multiple viewers, and each viewer may interact with multiple models. This is a many-to-many relationship.

With the combination of the concept #Publish/Subscribe Protocol, we can treat model as the event, view as the subscriber to the events and controller as the publisher of those events. Since the controller has the ability to provide new data to the model, there could be the case it is, too, a publisher to the model.

Although in the hierarchy, the view is higher than the model, they can be the models for the higher-level objects.

A theoretical better alternative to the MVC model is the Blackboard System#

Links to this page
  • The Pragmatic Programmer

    Treat documentation as a view of the code base adhere to the 202207041054# model unless you treat it like a model.

  • SOLID

    Make a local inversion of dependencies in the lower level abstraction and then move it to the higher level abstraction. The user should not directly interact with low level modules, instead they should rely on a general contractor with high abstractions, that encapsulate such dependencies, and use the module on the user’s behalf. The Pragmatic Programmer See more in 202207041054# or 202207041156#.

  • Publish/Subscribe Protocol

    We can further #decouple the model using Model-View-Controller (MVC)#.

  • Observer Pattern

    Observer Pattern is a #Design Pattern that could be used to implement #Views utilising the Publish/Subscribe Protocol. It is rather useful at decoupling# the presentations of the data from the data itself. There are two objects in this pattern: subject and observer. Observers don’t need to know each other’s existence, but depends on the subject. When there is a change happen in subject, the subscribed observers need to be notified to synchronise the change. This either done in subject to notify all observers that it keep track of (broadcast), or making it the observer’s responsibility to trigger the update when it is needed (centralised or peer-to-peer).

  • Documentation Guide

    Note: Treat documentation as one of the views# of the code base.

  • Blackboard System

    If implemented correctly, it can be of great replacement to the popular #Model-View-Controller (MVC). The following shows the example of libraries or implementation of such system:

#oop #data-structure