Модель–представление–адаптер ( MVA ) или посредник-контроллер MVC — это программный архитектурный шаблон и многоуровневая архитектура . В сложных компьютерных приложениях, которые предоставляют пользователям большие объемы данных, разработчики часто хотят разделить проблемы данных (модели) и пользовательского интерфейса (представления), чтобы изменения пользовательского интерфейса не влияли на обработку данных и чтобы данные можно было реорганизовать без изменения пользовательского интерфейса. MVA и традиционный MVC пытаются решить одну и ту же проблему, но с двумя разными стилями решения. Традиционный MVC размещает модель (например, структуры данных и хранилище), представление (например, пользовательский интерфейс) и контроллер (например, бизнес-логику) в треугольнике с моделью, представлением и контроллером в качестве вершин, так что некоторая информация передается между моделью и представлениями вне прямого контроля контроллера. Модель–представление–адаптер решает эту проблему несколько иначе, чем модель –представление–контроллер, размещая модель, адаптер или посредник-контроллер и представление линейно без каких-либо прямых связей между моделью и представлением. [1] [2]
Представление полностью отделено от модели, так что представление и модель могут взаимодействовать только через контроллер-посредник или адаптер между представлением и моделью. Благодаря такому соглашению только адаптер или контроллер-посредник имеет знания как о модели, так и о представлении, поскольку адаптация или посредничество между моделью и представлением является обязанностью исключительно адаптера или контроллера-посредника — отсюда и названия адаптер и медиатор. Модель и представление намеренно не замечают друг друга. В традиционном MVC модель и представление осведомлены друг о друге, что может допустить невыгодное связывание интересов представления (например, пользовательского интерфейса) с моделью (например, базой данных) и наоборот, когда архитектура могла бы лучше обслуживаться схемой базы данных и представлением информации в пользовательском интерфейсе, полностью отделенными друг от друга и позволяющими им радикально расходиться друг с другом. Например, в текстовом редакторе модель может быть лучшей таблицей частей (вместо, скажем, буфера зазоров или связанного списка строк ). Однако пользовательский интерфейс должен отображать конечное состояние изменений в файле, а не прямое , перегруженное информацией представление скрупулезных необработанных дельт-отмен и повторных операций в таблице элементов и инкрементных операций в этом файле с момента начала текущего сеанса редактирования.
Такое разделение интересов позволяет широкому спектру различных представлений косвенно получать доступ к одной и той же модели либо через один и тот же адаптер, либо через один и тот же класс адаптеров. Например, к одной базовой модели хранения данных, схеме и технологии можно получить доступ через разные представления, например, Qt GUI , Microsoft MFC GUI, GTK+ GUI, Microsoft .NET GUI, Java Swing GUI, веб-сайт Silverlight и веб-сайт AJAX , где (в отличие от традиционного MVC) модель полностью игнорирует то, какая информация поступает к этим пользовательским интерфейсам . Адаптер или класс адаптеров полностью игнорирует модель, что она поддерживает несколько пользовательских интерфейсов и, возможно, даже поддерживает это разнообразие одновременно. Для модели эти несколько типов пользовательских интерфейсов будут выглядеть как несколько экземпляров универсального пользователя, не обращающего внимания на тип технологии.
Аналогично, любой пользовательский интерфейс может намеренно игнорировать широкий спектр различных моделей, которые могут лежать в основе промежуточного контроллера или адаптера. Например, тот же веб-сайт может игнорировать тот факт, что он может обслуживаться (A) сервером базы данных SQL , таким как PostgreSQL , Sybase SQL Server или Microsoft SQL Server , который имеет бизнес-логику, встроенную в сервер базы данных через хранимые процедуры , и который имеет транзакции , которые сервер может откатить, или (B) сервером базы данных SQL, таким как MySQL , у которого отсутствует одна или несколько из этих возможностей, или (C) не-SQL RDF- базой данных, поскольку веб-сайт взаимодействует только с промежуточным контроллером или адаптером и никогда напрямую с моделью.
Кроме того, можно создать несколько адаптеров для изменения способа, которым одно представление представляет данные для заданной модели. Например, разные адаптеры могут налагать разные примитивные наборы данных, которые, в свою очередь, налагают разную бизнес-логику на одну и ту же базовую базу данных и на один и тот же внешне представленный веб-сайт. В этом сценарии класс разных адаптеров или промежуточных контроллеров может представлять вариации в бизнес-логике между одной и той же моделью базы данных и одним и тем же представлением веб-сайта.