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.

Principles

View and model do not communicate directly

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 being 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.

Model is intentionally oblivious of views

This separation of concerns permits a wide variety of different views to indirectly access the same model either via exactly the same adapter or via the same class of adapters. For example, one underlying data-storage model and schema and technology could be accessed via different views—e.g., Qt GUI, Microsoft MFC GUI, GTK+ GUI, Microsoft .NET GUI, Java Swing GUI, Silverlight website, and AJAX website—where (unlike traditional MVC) the model is kept completely oblivious of what information flows toward these user interfaces. The adapter or class of adapters keeps the model completely oblivious that it is supporting multiple of the user interfaces and perhaps even supporting this variety concurrently. To the model, these multiple types of user interface would look like multiple instances of a generic user oblivious of type of technology.

View is intentionally oblivious of models

Likewise, any one user interface can be kept intentionally oblivious of a wide variety of different models that may underlie the mediating controller or adapter. For example, the same website can be kept oblivious of the fact that it can be served (A) by an SQL database server such as PostgreSQL, Sybase SQL Server, or Microsoft SQL Server that has business logic built into the database server via stored procedures and that has transactions that the server may roll back or (B) by an SQL database server such as MySQL that lacks one or more of these capabilities, or (C) by a nonSQL RDF database, because the website interacts only with the mediating controller or adapter and never directly with the model.

Multiple adapters between the same model–view pair

Additionally, multiple adapters may be created to change the way one view presents data for a given model. For example, different adapters may impose different primitive data sets, that in turn impose different business logic for the same underlying database and for the same outwardly presented website. In this scenario, a class of various adapters or mediating controllers can represent the variations in business logic in between the same database model and the same website view.

See also

• Model–view–controller
• Model–view–presenter