(Этот ответ относится только к веб-приложениям. Для обычных графических интерфейсов см. Что такое MVP и MVC и в чем разница? .)
Традиционный MVC для приложений с графическим интерфейсом
Это не совсем относится к веб-приложениям, но вот как MVC традиционно работает в приложениях с графическим интерфейсом:
- Модель содержала бизнес-объекты.
- Контроллер реагировал на взаимодействия пользовательского интерфейса и перенаправлял их в модель.
- Представление «подписалось» на модель и обновлялось при изменении модели.
При таком подходе вы можете иметь (1) несколько способов обновления данного фрагмента данных и (2) несколько способов просмотра одних и тех же данных. Но вам не нужно сообщать каждому контроллеру о каждом представлении или наоборот - каждый может просто поговорить с моделью.
MVC на сервере
Rails, Django и другие серверные фреймворки обычно используют определенную версию MVC.
- Модель предоставляет приблизительно 1 класс на таблицу базы данных и содержит большую часть бизнес-логики.
- Представление содержит фактический HTML-код для сайта и как можно меньше кода. В основном это просто шаблоны.
- Контроллер отвечает на запросы HTTP, обрабатывает параметры, ищет объекты модели и передает значения в представление.
Кажется, это очень хорошо работает для серверных веб-приложений, и я был очень доволен этим.
MVP на клиенте
Однако, если большая часть вашего кода написана на JavaScript и работает в веб-браузере, вы найдете много людей, использующих MVP в наши дни. В этом случае роли немного отличаются:
- Модель по-прежнему содержит все основные объекты вашей бизнес-области.
- Представление представляет собой слой довольно тупых виджетов с небольшой логикой.
- Докладчик устанавливает обработчики событий на виджеты представлений, отвечает на события и обновляет модель. В другом направлении презентатор прислушивается к изменениям модели и, когда эти изменения происходят, обновляет виджеты представлений. Таким образом, презентатор представляет собой двунаправленный конвейер между моделью и представлением, которые никогда не взаимодействуют напрямую.
Эта модель популярна, потому что вы можете легко удалить слой вида и написать модульные тесты для презентатора и модели. Он также гораздо лучше подходит для интерактивных приложений, где все постоянно обновляется, в отличие от серверных приложений, где вы имеете дело с дискретными запросами и ответами.
Вот некоторые справочные материалы:
Google MVP + шина событий
Это новый подход, описанный в этом видео от команды Google AdWords . Он хорошо работает с кэшированием, автономными приложениями HTML 5 и такими сложными инструментальными средствами на стороне клиента, как GWT . Он основан на следующих наблюдениях:
- Все, что угодно , возможно, должно происходить асинхронно, поэтому спроектируйте все так, чтобы оно было асинхронным с самого начала.
- Тестирование представлений на основе браузера выполняется намного медленнее, чем тестирование моделей и презентаторов.
- Данные вашей реальной модели хранятся на сервере, но у вас может быть локальный кеш или автономная база данных HTML 5.
В этом подходе:
- Вид очень тупой, и вы можете заменить его фиктивными объектами при запуске юнит-тестов.
- Объекты модели - это просто контейнеры для данных без реальной логики. У вас может быть несколько объектов модели, представляющих одну и ту же сущность.
- Ведущий слушает события с точки зрения. Всякий раз, когда ему нужно обновить или прочитать из модели, он отправляет асинхронное сообщение на сервер (или в локальную службу кэширования). Сервер отвечает отправкой событий на «шину событий». Эти события содержат копии объектов модели. Шина событий передает эти события различным докладчикам, которые обновляют присоединенные представления.
Так что эта архитектура по своей сути асинхронна, ее легко протестировать, и она не требует серьезных изменений, если вы хотите написать автономное приложение HTML 5. Я еще не использовал это, но это следующий в моем списке вещей, чтобы попробовать. : -)