Здравствуйте, Аноним, Вы писали:
А>Сколько не подбирался к этой теме, сколько не читал статей, не спрашивал знатоков, даже оригинальную статью про MVC читал, так и не понял необходимости промежуточных слоев между Model и View.
А>MVC — это какой-то удивительный паттерн, который вроде все понимают, кроме меня, но что-то в этом понимании не то, ибо оно у всех разное. Если вы поищете изображения в гугле по запросу "MVC", вы увидите практически все варианты расположения стрелочек между квадратиками M, V и C. Если взять оригинальную статью по MVC, у автора Controller был подрисован к View, и вся его функциональность состояла в обработке ввода пользователя. То есть у автора MVC фактически была Model-View, а Controller — вспомогательный компонент View.
А>В какой-то момент в интерпретации, например, Microsoft, Controller стал таким важным, что встал между Model и View. А у других три компонента соединены в цикл с разными вариантами стрелочек.
А>У кого-то Controller — это вообще основная часть, где все делается, а model — это просто база данных.
А>Если говорить о тестировании, то, в принципе, ничего не мешает делать его без контроллера.
А>Пока что у меня в голове от MVC остался только какой-то сумбур.
А>То ли я тупой, то ли это какой-то заговор, то ли действительно с этими M*C моделями что-то не так.
Расскажу неполную, неточную и выдуманную историю MV* паттернов.
Часть первая. Зарождение MVC.
Не бывает паттернов в вакууме. Они все зависят от языков, технических средств и требований к программам.
На заре графических ОС все приложения строились на основе цикла сообщений и обработки сообщений ОС. Еще не было компонентной модели, Delphi, C++ Builder, VB и прочих RAD тулов. Большая часть приложений была редакторами каких-либо документов, то есть предлагала средства для графического представления некоторой "модели". Надо понимать что это далеко не тоже самое, что толстый клиент многопользовательской системы (СУБД), там понятие модели другое и диктует другие паттерны.
Та вот по веянием ООП решили модель сделать объектом. Чтобы не нарушать SOLID не стали в модель вносить взаимодействие с пользователем. Чтобы отображать модель на экране использовался объект View, который просто брал данные у модели и рисовал. Все действия пользователей все так же попадали в виде событий в message loop. Для того чтоб в ООП стиле обрабатывать события придумали контроллер, который реагируя на события обновлял модель, а также пинал View для обновления интерфейса.
Вкратце суть MVC:
1) Управление приходит в Controller
2) Controller обновляет Model
3) Controller или Model (тут без разницы) пинает view
4) View отображает Model на экране
5) Model — объект, не база данных, не remote proxy, а обычный кусок памяти и набор методов.
Преимущества очевидны. Для изменения представления надо трогать только view, для изменения поведения только Controller.
Со временем люди забыли предпосылки MVC, такие как message loop, но продолжили рисовать те же квадратики и стрелочки, все больше запутывая других.
Часть вторая. Зарождение MVP.
В середине 90-х годов огромную популярность приобрели RAD средства, использующие компонентную модель. Теперь не надо было вручную писать циклы обработки событий, достаточно было кинуть компонент на форму и он уже работал.
Разработчики ликовали, апологеты ООП были в глубоком унынии. Как же так, один компонент отвечает и за данные, и за рисование, и за обработку событий.
Кроме того это была эпоха корпоративных приложений, когда "модель" стала совсем не такой как в MVC. Теперь нельзя было просто изменять свойства объекта и сохранять в файл по нажатию кнопки.
Поэтому все что за пределами GUI объявили Model. Сам визуальный компонент назвали View, он показывает данные и обрабатывает ввод. Связующее звено между Model и View, которое подписывалось на события view и пинало его методы, а также обновляло данные назвали Presenter. Presenter обычно оказывается жестко привязанным ко view, так что никакого реюза не происходит.
Но есть заметное преимущество, в корпоративных приложениях Model оказывается на два порядка более изменчивым, чем в классическом MVC, поэтому прослойка между View и Model положительно сказывается на приложении.
Вкратце суть MVP:
1) Управление приходит во View
2) View вызывает presenter
3) Presenter общается с моделью
4) Presenter изменяет свойства View
5) Model — все что не GUI
6) Модель полностью отделена от представления
В зависимости от распределения обязанностей между View и Presenter придумали вариации Active\Passive View и еще чтототам.
Часть третья. реинкарнация MVC.
В 2000 году огромную популярность приобрел веб. Теперь это не только странички с надписью Under Construction, а платформа для приложений.
В вебе последовательность работы напоминает message loop. То есть приложение вынуждено реагировать на события (их гораздо меньше, чем в десктопе, поэтому веб гораздо проще). С другой стороны простой модели, как в классическом MVC в вебе в принципе не может быть.
Чтобы побыстрее насадить везде правильную архитектуру вытащили старый MVC, но слега его перетряхнули. View полностью отделили от Model (негоже из разметки страниц лезть в базу). В качестве View взяли шаблонизаторы HTML, Controller стал обрабатывать запросы, получать данные модели, и передавать их в шаблонизатор.
Вкратце суть web-MVC:
1) Управление приходит во Controller
2) Controller пинает Model
3) Controller передает данные на view
4) View генерит HTML
5) Model — все что не GUI
По сути это смесь MVP и MVC, но об этом никто не говорит, потому что уже не помнит сути изначального MVC.
Кстати это придумано далеко не Microsoft, Microsoft сделал свой web-MVC только в 2008 году и обозвал данные, передаваемые между Model и View, словом ViewModel. Но когда это вызвало путаницу с MVVM паттерном, о котором ниже, то ViewModel начал называть просто Model породив страшную неразбериху.
Часть четвертая. MVVM.
Я про MVVM узнал в 2008 году в контексте Microsoft и WPF. В отличие от предыдущих гуевых фреймворкв WPF умел делать декларативную двустороннюю привязку к данным.
Это позволило взять классический MVP, но в качестве view использовать чисто визуальные компоненты, которые содержат минимум поведения, а все поведение перенести в presenter.
При использовании привязки к данным presenter вырождался в класс, который выставлял наружу набор свойств и методов (команд). Этот класс начали называть ViewModel.
Одно из заметных отличий от MVP в том, что ViewModel не важно какой визуальный компонент привязывается к нему. Поэтому возможен реюз и большая гибкость в интерфейсе.
Вкратце суть MVVM:
1) Управление приходит во View, но программисту все равно, ибо view примитивен, для его View не существует.
2) View привязывается к ViewModel и все события попадают во ViewModel
3) ViewModel общается с Model и изменяет свои свойства
4) View меняет представление в зависимости от свойств ViewModel
5) Model — все что не GUI
Со временем подобный паттерн попадет во все уважающие себя GUI фрейиворки, в том числе на JavaScript.
Из-за традиционного бардака в JS как только MVVM не называют.
Еще раз внимательно посмотрите на предпосылки тех или иных паттернов. Если вам пытаются "продать" универсальный паттерн или архитектуру, то вам, скорее всего, врут.
