Model–view–adapter

Model–view–adapter (MVA) or mediating-controller MVC is a software architectural pattern and multitier architecture. In complex computer applications that present large amounts of data to users, developers often wish to separate data (model) and user interface (view) concerns so that changes to the user interface will not affect data handling and that the data can be reorganized without changing the user interface. MVA and traditional MVC both attempt to solve this same problem, but with two different styles of solution. Traditional MVC arranges model (e.g., data structures and storage), view (e.g., user interface), and controller (e.g., business logic) in a triangle, with model, view, and controller as vertices, so that some information flows between the model and views outside of the controller's direct control. The model–view–adapter solves this rather differently from the model–view–controller by arranging model, adapter or mediating controller and view linearly without any connections whatsoever directly between model and view.

The view is completely decoupled from the model such that view and the model can interact only via the mediating controller or adapter between the view and the model. Via this arrangement, only the adapter or mediating controller has knowledge of both the model and the view, because it is the responsibility of solely the adapter or mediating controller to adapt or mediate between the model and the view—hence the names adapter and mediator. The model and view are kept intentionally oblivious of each other. In traditional MVC, the model and view are made aware of each other, which might permit disadvantageous coupling of view (e.g., user interface) concerns into the model (e.g., database) and vice versa, when the architecture might have been better served by the schema of the database and the presentation of information in the user-interface are divorced entirely from each other and allowed to diverge from each other radically. For example, in a text editor, the model might best be a piece table (instead of, say, a gap buffer or a linked list of lines). But, the user interface should present the final resting state of the edits on the file, not some direct information-overload presentation of the piece-table's meticulous raw undo-redo deltas and incremental operations on that file since the current editing session began.

...
Wikipedia