Существует множество статей об архитектурных шаблонах, но лишь немногие из них просты для понимания. Основные проблемы в большинстве статей заключаются в следующем:
- Область действия задана неправильно: внешний MVC-это модифицированный MVC, который явно отличается от внутреннего MVC и не может быть обобщен.
- Практических примеров нет: реальные примеры соответствуют повседневной работе, без которой трудно резонировать, в результате чего возникает проблема один раз увидеть и один раз забыть.
- Нет четкой цели: каков реальный смысл понимания шаблона архитектуры? Расположение виртуального DOM и компонентизация в MV*
Тема слишком большая. Должно быть, здесь много ошибок и упущений. Я также настоятельно призываю вас указать на это.
1.1 Внутренний MVC и внешний MVC
С точки зрения реализации его можно разделить на серверный MVC и интерфейсный MVC. Различия между двумя MVC заключаются в следующем:
Как вы можете видеть, Интерфейсный MVC на самом деле представляет собой MVC, отделенный от серверного MVC V, чтобы решить проблему модульности JS-интерфейса. Нет прямой связи с внутренним MVC. В интерфейсном MVC на долю M приходится очень низкая доля, относящаяся только к алгебраическим данным. Доля серверной части очень мала, только часть шаблона.
1.2 MVC/MVP/MVVM
Ясно, что различия между тремя архитектурами заключаются в том, что” Соединение M и V ” является частью. Давайте проведем сравнение для этой части:
- Контроллер Отвечает за мониторинг пользовательских событий просмотра, получение данных, Контроллер выполняет некоторую обработку, а затем отображает представление.
Конечно, в некоторых внутренних архитектурах MVC модель также может напрямую отображать шаблоны представлений, но это всего лишь реализация различных вариантов, которая здесь не обсуждается.
Однако из-за сложности логики в любое время такая обработка сталкивалась с проблемами, которые трудно отлаживать. Поскольку представление должно выполняться в среде пользовательского интерфейса, а модель или контроллер и представление тесно связаны, невозможно проверить правильность только логики приложения. Когда что-то идет не так, поскольку модули соединены вместе, невозможно быстро определить, в каком модуле проблема. В результате появилась модель MVP.
Presenter По сравнению с контроллером, Presenter вызывает интерфейс, предоставляемый слоем представления, для визуализации Модели. Это имеет несколько преимуществ:
- Интерфейсно-ориентированное программирование
- Лучшее разъединение
- Легко проводить модульное тестирование
Теперь, когда P и V разделены, P может самостоятельно выполнять модульные тесты. Структура программного обеспечения разделена более четко, логика понятна, а отладка удобна. Но все это исходит из предпосылки, что уровень представления обеспечивает интерфейсы. Когда пользовательский интерфейс сложен, существует множество интерфейсов, которые должен предоставлять уровень представления, что само по себе является затратами на разработку и отладку. Таким образом, появился MVVM.
- ViewModel MVVM создает набор данных о состоянии в виртуальной машине как абстракцию состояния представления по сравнению с API, который Представление должно предоставить в MVP. Затем данные о состоянии в виртуальной машине выравниваются с отображаемым состоянием экрана с помощью двусторонней привязки данных. Таким образом, логика отображения в виртуальной машине может управлять состоянием представления только путем изменения соответствующих данных состояния, что позволяет избежать разработки большого количества интерфейсов в представлении.
Есть ли какие-либо недостатки виртуальной машины? Да, когда пользовательский интерфейс относительно прост, использование виртуальной машины усложнит бизнес-логику, вызывая подозрения в чрезмерном дизайне. Таким образом, виртуальная машина подходит только для сложных проектов взаимодействия с пользовательским интерфейсом.
Chestnut_: Теперь пользователь опускается и обновляет страницу. На странице 10 новых новостей. Общее количество новостей изменилось с 10 до 20. Затем по очереди выполняется обработка MVC, MVP и MVVM:
1. View gets the drop-down event and notifies Controller
2. Controller initiates a request to the background model to refresh the content of the request for a drop-down
3. Model gets 10 news data and passes it to Controller
4. Controller gets 10 news data, maybe does some data processing, and then renders View with the processed data.
MVC: Get the UI node and render 10 news
MVP: Rendering 10 news items through the interface provided by View
MVVM: No operation is required, as long as the data of VM changes, View changes directly through data bidirectional binding.Самое большое значение имеет Мышление с точки зрения Создателя Почему они проектируют таким образом и каковы преимущества этого? Конечно, это также помогает нам понять другие соответствующие знания. Однажды в будущем, когда мы столкнемся с более сложными ситуациями, которые не могут быть решены с помощью сегодняшней MVVM, мы сможем следовать этому ходу мышления и перепроектировать архитектуру, чтобы излучать наш собственный свет.
Примечание: Виртуальный DOM и компонентизация Будь то виртуальный DOM или компонентизация, это стратегия развития, а не архитектурная модель. Другими словами, они и MV* являются двумя измерениями. Поэтому не имеет смысла вовлекать виртуальный DOM и модуляризацию в различия между MVC, MVP и MVVM.
- Сходства и различия между MVC, MVP и MVVM
- Размышления о интерфейсном и серверном MVC