Модель-представление-адаптер ( MVA ) или MVC-посредник - это программный архитектурный шаблон и многоуровневая архитектура . В сложных компьютерных приложениях, которые представляют большие объемы данных пользователям, разработчики часто хотят разделить проблемы данных (модели) и пользовательского интерфейса (представления), чтобы изменения в пользовательском интерфейсе не повлияли на обработку данных и чтобы данные можно было реорганизовать без изменения. пользовательский интерфейс. MVA и традиционный MVCоба пытаются решить одну и ту же проблему, но с двумя разными стилями решения. Традиционный MVC размещает модель (например, структуры данных и хранилище), представление (например, пользовательский интерфейс) и контроллер (например, бизнес-логику) в треугольнике с моделью, представлением и контроллером в качестве вершин, так что некоторая информация течет между модель и виды вне прямого контроля контроллера. Адаптер модель-представление-представление решает эту проблему несколько иначе, чем модель-представление-контроллер , располагая модель, адаптер или промежуточный контроллер и представление линейно, без каких-либо прямых связей между моделью и представлением. [1] [2]
Вид и модель не взаимодействуют напрямую
Представление полностью отделено от модели, так что представление и модель могут взаимодействовать только через посреднический контроллер или адаптер между представлением и моделью. Благодаря такому расположению только адаптер или контроллер-посредник имеет сведения как о модели, так и о представлении, поскольку ответственность за адаптацию или посредничество между моделью и представлением лежит исключительно на адаптере или контроллере-посреднике - отсюда и имена адаптер и посредник. Модель и вид намеренно не обращают внимания друг на друга. В традиционном MVC модель и представление осведомлены друг о друге, что может допускать невыгодное объединение проблем представления (например, пользовательского интерфейса) с моделью (например, базой данных) и наоборот, когда архитектура могла бы лучше обслуживаться схема базы данных и представление информации в пользовательском интерфейсе полностью отделены друг от друга и позволяют радикально отличаться друг от друга. Например, в текстовом редакторе , модель может лучше всего быть кусок таблицы (вместо, скажем, буфер разрыва или связанный список из линий ). Но пользовательский интерфейс должен представлять окончательное состояние покоя редактирования файла, а не какое-то прямое представление с перегрузкой информации тщательно продуманных необработанных дельт отмены-повтора и инкрементных операций над этим файлом с момента начала текущего сеанса редактирования.
Модель намеренно не обращает внимания на взгляды
Такое разделение задач позволяет множеству различных представлений косвенно обращаться к одной и той же модели либо через один и тот же адаптер, либо через один и тот же класс адаптеров. Например, к одной базовой модели, схеме и технологии хранения данных можно получить доступ через разные представления, например, Qt GUI , Microsoft MFC GUI, GTK + GUI, Microsoft .NET GUI, Java Swing GUI, веб-сайт Silverlight и веб-сайт AJAX - где ( в отличие от традиционного MVC) модель полностью игнорирует, какая информация течет к этим пользовательским интерфейсам . Адаптер или класс адаптеров позволяют модели полностью забыть о том, что она поддерживает несколько пользовательских интерфейсов и, возможно, даже поддерживает это разнообразие одновременно. Для модели эти несколько типов пользовательского интерфейса будут выглядеть как несколько экземпляров обычного пользователя, не обращающего внимания на тип технологии.
View намеренно не обращает внимания на модели
Точно так же любой пользовательский интерфейс может быть намеренно не обращать внимания на большое количество различных моделей, которые могут лежать в основе посреднического контроллера или адаптера. Например, один и тот же веб-сайт может игнорироваться тем фактом, что его может обслуживать (A) сервер базы данных SQL, такой как PostgreSQL , Sybase SQL Server или Microsoft SQL Server , бизнес-логика которого встроена в сервер базы данных через хранимые процедуры. и в котором есть транзакции, которые сервер может откатить, или (B) сервер базы данных SQL, такой как MySQL , у которого отсутствует одна или несколько из этих возможностей, или (C) база данных RDF, отличная от SQL, поскольку веб-сайт взаимодействует только с посредником. или адаптер и никогда напрямую с моделью.
Несколько адаптеров между одной парой модель – вид
Кроме того, можно создать несколько адаптеров, чтобы изменить способ представления данных в одном представлении для данной модели. Например, разные адаптеры могут налагать разные примитивные наборы данных, которые, в свою очередь, налагают разную бизнес-логику для одной и той же базовой базы данных и для одного и того же внешнего веб-сайта. В этом сценарии класс различных адаптеров или контроллеров-посредников может представлять различия в бизнес-логике между одной и той же моделью базы данных и одним и тем же представлением веб-сайта.
Смотрите также
- Модель – представление – контроллер
- Модель – представление – ведущий
Рекомендации
- ^ Замудио Лопес, Шейди Анель; Сантаолая Сальгадо, Рене; Фрагозо Диас, Оливия Грасиела (июнь 2012 г.). «Реструктуризация объектно-ориентированных фреймворков в архитектуру модель – представление – адаптер». IEEE Latin America Transactions (на испанском языке). 10 (4): 2010–2016. DOI : 10,1109 / TLA.2012.6272488 .
- ^ Тируватукал, Джордж К .; Лойфер, Константин (2018), «Управление параллелизмом в мобильных пользовательских интерфейсах с примерами в Android», Темы в параллельных и распределенных вычислениях , Springer, Cham, стр. 243–285, doi : 10.1007 / 978-3-319-93109-8_9 , ISBN 9783319931081