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