Gravure d’un calmar géant échoué en 1877 sur la baie Trinity, à Terre-Neuve.

Загадка Кракена

В своей предыдущей заметке (Все новое это хорошо забытое старое), я описал свое видение концепции Reenskaug-MVC 1979 года, которая так и не была воплощена в жизнь, так же я затронул тему Model-View-Octopus или, как я его называю, Кракена, термина введенного Беном Яффе.

Я “выкатил” ряд претензий к Flux архитектуре и упомянул, что начал “выпиливать” ее из проекта. Может сложится впечатление, что я против этого архитектурного стиля, что я за возврат к старым терминам, что мне не нравится Facebook или я люблю “велосипеды” (хотя я и вправду люблю велосипеды).

Это все не совсем так. Я хотел бы более развернуто описать свое видение и продолжить делиться своим Braindump, но вначале, мне кажется, нужно до конца разобраться с таким явлением как Кракен.

MVO очень обобщающий термин. Рассматривая его, можно подумать, что все эволюции MVC одно и тоже, нет никакой существенной разницы между этими концепциями. Это очень выгодная позиция, смотреть на все через эту точку зрения. Но как дело обстоит на самом деле? Я не рассматривал другие концепции в предыдущей заметке, просто упомянул их. Так же я так и не ответил, откуда появился осьминог. Давайте попробуем взглянуть, по примеру предыдущей заметки, на самые первые формулировки этих так называемых “шаблонов”, проследить их хронологию и попутно разгадать загадку Кракена.

Подходы MV* предназначены для удовлетворения потребностей интерактивных приложений путем разделения проблем, связанных с различными компонентами в рамках их соответствующих архитектур.

Важная оговорка, что подобные архитектурные стили не сводятся к определенным классам, структурам или шаблонам проектирования. Это абстракции, которые позволяют логически разделить ответственность в нашей системе между определенными слоями.

По крайней мере такова была изначальная задумка.

Контроллер может быть как конкретным классом, так и целой инфраструктурой с необходимыми функциями. Изначально это лишь абстракция или слой.

Термин разделение ответственности (Separation of Concerns / SoC) ввел Эдсгер Дейкстра еще аж в 1974. Все архитектурные концепции, описанные ниже, это как раз попытки реализации этого самого разделения.

В то же время каждый из этих шаблонов несколько отличается в своих мотивах и применимости к различным целям дизайна. Следовательно будет ошибкой обобщать их под одной аббревиатурой.

Мне нравится замечание Дерека Грира о том, что такие шаблоны лучше всего рассматривать как нечто большее в сфере искусства, чем науки. Архитектурные стили не эквивалент компьютерной науки или закону тяготения Ньютона. Они просто представляют нашу постоянно меняющуюся попытку применить лучший подход при разработке приложений.

Наконец, рассматривая использование этих шаблонов, помните, что их применение это решение конкретной проблемы, а не дань моде. Использование шаблонов проектирования должно быть результатом того, что началось с проблемы, для которой существующий шаблон был известен или был признан применимым. В клиентской разработке многие из этих концепций воплотились в жизнь в виде популярных библиотек и фреймворков, holy wars при их сравнении это, порой, наше излюбленное дело.

Ну что ж, хватит вступлений:

-Док, да это же Делориан!

-Да, Марти. Мы опять отправляемся назад в прошлое!

Back to the Future (film)

Smalltalk-80 MVC (VisualWorks MVC)

1987 год. Именно в этом году появилась заметка Стива Бербека, которая называлась “Applications Programming in Smalltalk-80 (TM):How to use Model-View-Controller”. Позже в 1992 она была немного дополнена и актуализирована согласно соответствующей версии Smalltalk-80.

Model-View-Controller — это концепция разделения проблем домена приложения, представления и ввода пользователя посредством периферийных устройств.

Как раз в этой заметке описывается та самая первая реализация MVC, модифицированная версия Reenskaug-MVC, часть библиотеки классов Xerox PARC.

Диаграммы того времени нет, но из описания можно набросать примерную схему:

(VisualWorks MVC)

Модель (Model) относится к данным и бизнес-функциям приложения. Это непосредственно модель предметной области, где объекты используются для моделирования реальных объектов и процессов, представляя их свойства и поведение.

Представление (View) — дерево экранов и виджетов, используемых для отображения данных предметной области.

Контроллер (Controller) — это компонент, который реагирует на пользовательский ввод, такой как ввод данных и команды, выдаваемые с клавиатуры или мыши.

Триада Model-View-Controller реализуется для каждого объекта системы, которым может манипулировать пользователь.

Модель представляет состояние, структуру и поведение данных, просматриваемых и управляемых пользователем. Модель ничего не знает о Представлении или Контроллере и может быть модифицирована этими компонентами или другими объектами системы.

Компоненты Представление и Контроллер работают вместе, чтобы позволить пользователю просматривать и взаимодействовать с моделью.

Контроллер может напрямую уведомить Представление об изменениях. Контроллер перехватывает ввод пользователя с периферийных устройств и отвечает соответствующим образом. Некоторые действия пользователя приведут к взаимодействию с моделью, например, к изменению данных или вызову методов, в то время как другие действия пользователя могут привести к визуальным изменениям в представлении. Это как раз тот случай, когда надо изменить цвет виджета или добавить какую либо интерактивность, что в свою очередь не является частью бизнес данных.

Каждое представление связано с одним контроллером, и каждому контроллеру соответствует один просмотр. Оба компонента Представление и Контроллер поддерживают прямую связь с моделью.

В реализации Smalltalk-80 все крутится вокруг шаблона Наблюдатель (Observer). Когда необходимо уведомить об изменении данных связку Представление-Контроллер, Модель использует этот шаблон для отправки сообщения.

Из вышеописанного можно сделать вывод, что самое запутанное и технически-сложное место в концепции, это как раз реализация связи Наблюдатель-Слушатели. В одной из своих статей на данную тему, Мартин Фаулер упоминает, что поведение системы в этом месте самое неявное и без отладчика понять происходящее сложно.

Распространенное заблуждение относительно связи между компонентами первой реализации MVC состоит в том, что назначение Контроллера — отделить Представление от Модели. Хотя на самом деле это разделение достигается как раз с помощью шаблона Наблюдатель, а не через Контроллер. Контроллер был задуман как посредник между конечным пользователем и приложением, а не между Представлением и Моделью.

Надо отметить, что данная реализация более нигде не используется и не получила продолжения в других технологиях и платформах, хотя и послужила катализатором к созданию новых ее версий.

Web-MVC или Model-2

С появлением интернета появился и аналог исходного MVC для использования его с web-приложениями. Подобно исходной концепции о разделении обязанностей, концепция Web-MVC помогает разделить проблемы предметной области (домена), клиентской презентации и обработки входных данных на стороне сервера в специализированные компоненты.

Формирование этой концепции произошло естественным образом, поскольку на протокол HTTP и представления, в виде HTML, программисты смотрели через призму ООП и уже зарекомендовавших себя архитектурных стилей, таких как MVC. Web-приложения обеспечивают возможность обслуживания динамического контента для web-клиентов путем обработки входящих HTTP-запросов через серверные компоненты. По мере появления различных подходов к созданию web-сайтов необходимость обработки и маршрутизации входящих запросов обычно приводила к созданию кода инфраструктуры, который выполнял ту же логическую задачу, что и исходные контроллеры Smalltalk-80.

HTML-контент интерпретируется как Представление, Контроллер обрабатывая HTTP-запрос может вернуть новый контент или изменить модель.

В частности, компания Apple, после внедрения технологии WebObject, активно популяризировала MVC в web.

Характерной чертой в разработке web-приложений 1990-х годов был стандарт Common Gateway Interface (CGI). Приложения CGI могут принимать форму скомпилированного или интерпретируемого кода и порождаться как отдельные процессы для обработки входящих HTTP-запросов.

В 1997 году Sun Microsystems опубликовала спецификацию Java Servlet 1.0 для улучшения приложений на основе CGI, обрабатывая HTTP-запросы как отдельные потоки в размещенной виртуальной машине Java (JVM).

В 1999 году Sun построила свою инфраструктуру, внедрив спецификацию Java Server Pages (JSP) 1.0. По аналогии с Microsoft Active Server Pages (ASP), представленной в декабре 1996 года, Java Server Pages обеспечили абстракцию для создания сервлетов, позволяя разработчикам создавать специализированные HTML-шаблоны.

Первый проект спецификации JSP включал руководство с двумя подходами к использованию новой технологии. Первым было эффективное разделение Модель-Представление, в котором запросы направлялись непосредственно к JSP, которые, в свою очередь, взаимодействовали бы с моделью приложения ("JavaBeans” в Java-языке). Второй подход, рекомендованный для более сложных приложений, был эффективно разделен Model-View-Controller, где запросы направлялись в Java-сервлеты, которые взаимодействовали с моделью и впоследствии передавали управление JSP для отображения представления обратно в браузер. Обновленный проект спецификации JSP относился к этим подходам как к Model-1 и Model-2 соответственно.

(Model 1 — JSP Spec 1.0)
(Model 1 — JSP Spec 1.0)

Хотя в спецификации не было связи с шаблоном Smalltalk-80 MVC, сходство было отмечено в статье, появившейся в журнале Java World в декабре того же года.

(Model 2 — JavaWorld Magazine)

Фактически архитектуру Model-2 можно рассматривать как “серверную” реализацию Smalltalk-80 MVC.

Заслуга в популяризации концепции Model-2 в основном принадлежит Крейгу Р. Маккланахану и его реализации этой архитектуры в лице Struts. Struts была представлена ​​в качестве основы MVC и стала широко принятой в сообществе разработчиков Java, а также фундаментом для разработки множества производных структур в последующие годы.

(Struts from DZone)

Front Controller

Web-MVC эволюционировал в Front Controller. Перед web-разработчиками ставился ряд задач связанных с обработкой общих проблем инфраструктуры, появилась необходимость в маршрутизаторе или общем контроллере, который был бы точкой входа для остальных обработчиков. Примерами общих проблем, с которыми сталкивается Front Controller, могут быть безопасность, управление состоянием сеанса, фильтрация ввода, кэширование или задачи общего управления.

Одна из самых популярных реализаций этой концепции это Spring-MVC:

(docs.spring.io)

Получив HTTP-запрос, Front Controller выполняет любое общее поведение, а затем использует информацию, полученную из запроса, чтобы найти соответствующий контроллер. После того, как контроллер находится, запрос делегируется для дальнейшей обработки.

Как только контроллер получает конкретный запрос, соответствующие операции выполняются над моделью, и управление передается представлению.

В связи с тем, что web-приложения не имеют состояния, просмотры отображаются по-новому при каждом запросе. Таким образом, шаблон Наблюдатель не используется в процессе обновления представления. Чтобы визуализировать представление с соответствующим состоянием, контроллер делает необходимое состояние доступным в форме модели. В зависимости от реализации, View затем отображает выходной поток или анализируется отдельным процессором для визуализации выходного потока на основе состояния представления, предоставляемого контроллером.

Model-View-Presenter (Taligent MVP)

Вариаций данной концепции существует несметное множество. Я же обращусь к описанию самой первой реализации под названием Taligent Model-View-Presenter.

Модель Taligent Model-View-Presenter разделяет взаимодействие представления и пользователя, бизнес данные, спецификацию данных и манипулирование данными в специализированные компоненты.

Концепция MVP была основана на модели программирования Taligent, на которую непосредственно влиял исходный шаблон Smalltalk-80 MVC. Модель впервые формально описана Майком Потелем в 1996 году во время работы в Taligent в работе под названием “MVP: The Taligent Programming Model for C++ and Java

Taligent был запущен Apple Computer, Inc. в качестве совместного предприятия с IBM (а затем присоединился Hewlett Packard), прежде чем стать дочерней компанией IBM в конце 1995 года. Многие элементы исходного шаблона MVP начали формироваться в Apple под руководством Ларри Теслера, который ранее работал в Xerox PARC, где он был одним из участников разработки и внедрения Smalltalk.

Исходный документ пестрит схемами. Фактически MVP это SoC следующего уровня для Smalltalk-80 MVC. По мере рассмотрения концепции Smalltalk-80 MVC авторы MVP задают 6 вопросов. Определяя ответы, термин контроллер исчезает. Его заменяет более узкоспециализированный компонент Презентатор (Presenter), который выступает в качестве соединительного звена между новыми терминами.

Вводятся понятия новых объектов системы, их взаимная коммуникация определяется дополнительными терминами.

В документе присутствует описание этой концепции применительно к web:

Модель (Model) относится к данным и бизнес-функциям приложения.

Выборки (Selections) — это компоненты, которые определяют, какую часть данных внутри модели следует подвергнуть изменению. Примерами могут быть выборки, которые определяют строки, столбцы или отдельные элементы, которые соответствуют определенным критериям.

Команды (Commands) — это компоненты, которые определяют операции, которые могут выполняться над данными. Примерами могут быть удаление, печать или сохранение данных в модели.

Представление (View) — визуальное представление Модели и состоит из экранов и виджетов, используемых в приложении.

Взаимодействия (Interactors) — это компоненты, которые определяют, как события пользователя сопоставляются с операциями, выполняемыми в модели, такими как движения мыши, ввод с клавиатуры и выбор флажков или пунктов меню.

Презентатор (Presenter) — это компонент, который организует общее взаимодействие других компонентов в приложении. Его роли включают создание соответствующих моделей, выборок, команд, представлений, взаимодействий и управление рабочим процессом внутри приложения.

Dolphin Smalltalk MVP

Команда Dolphin Smalltalk (реализация языка для платформы Microsoft Windows) упростила концепцию Taligent MVP, исключив из формального описания шаблона Interactors, Commands и Selection. Это, в свою очередь, упростило роль Presenter, изменив его с контроллера подсистемы на компонент, который опосредует обновления модели от имени представления.

Модель Dolphin Model-View-Presenter была адаптирована из шаблона Taligent Model-View-Presenter для решения проблем гибкости, с которыми команда разработчиков Dolphin имела дело в своей работе. Одно из ранних соображений команды (1995 год) включало вариацию шаблона MVC, используемую в VisualWorks ParcPlace Systems (это все та же реализация Smalltalk-80 MVC).

Рассматривая дизайн VisualWorks MVC команда Dolphin отметила сложность этой концепции, связь Представления и Модели очень запутывает команду (эта взаимосвязь носила название Application Model и она является отправной точкой другой концепции, которая очень хорошо знакома клиентским разработчикам — Model-View-ViewModel).

Они также обнаружили, что концепция MVC-контроллера, основной целью которой было реагировать на пользовательские события, не была хорошо связана с более современными платформами разработки, чьи собственные виджеты непосредственно обрабатывали пользовательские события.

После встречи с моделью Taligent MVP команда Dolphin сделала вывод, что эта концепция более применима для достижения поставленных целей проектирования. В то время как они видели преимущества в шаблоне MVP Taligent, они ошибочно полагали, что Taligent выработал свой шаблон из реализации MVC VisualWorks и исключил использование Application Model, перемещая проблемы логики представления от Модели к Презентатору.

Они описали это как “скручивание триады” (TWISTING THE TRIAD: The evolution of the Dolphin Smalltalk MVP application framework 2000), хотя это не совсем точно отражает различия между шаблоном MVP Taligent и оригинальным шаблоном Smalltalk-80 MVC.

Из-за этого недоразумения они рассматривали компонент Презентатор, как замену Application Model в MVC VisualWorks, а не эволюцию Контроллера в Smalltalk-80 MVC.

Результирующий шаблон, реализованный командой Dolphin Smalltalk, был лишен большинства компонентов, которые придали MVP оригинальный отличительный признак от MVC, хотя и ввели собственные отличительные свойства.

Модель (Model) относится к данным и бизнес-функциям приложения.

Представление (View) — визуальное представление Модели и состоит из экранов и виджетов, используемых в приложении.

Презентатор (Presenter) — это компонент, который содержит логику Представления, которая взаимодействует с Моделью.

На первый взгляд, различия между MVP Dolphin Smalltalk и Smalltalk-80 MVC трудно найти. Обе концепции содержат триаду. Обе содержат модель и представление, которые практически идентичны по функциям. В обновлении модели участвуют как контроллер Smalltalk-80, так и Dolphin Smalltalk Presenter. Обе концепции используют шаблон Наблюдатель, чтобы обновить представление, когда изменения происходят с моделью. Со всеми этими сходствами понятно, почему так много путаницы окружает понимание того, как шаблон Model-View-Presenter выделяется отдельно от шаблона Model-View-Controller. Ключ в понимании основных функций, которые должны выполнять контроллеры в своих соответствующих триадах.

В исходном шаблоне Model-View-Controller основной целью Контроллера было перехват ввода пользователя. Роль Контролера в обновлении Модели была в значительной степени побочным продуктом этой функции, а не неотъемлемой частью ее цели.

И наоборот, в шаблоне Model-View-Presenter для Dolphin Smalltalk основной целью Презентатора было обновление модели. Роль ведущего в перехвате событий, делегированных Представлением, была в значительной степени побочным продуктом этой функции, а не неотъемлемой частью ее цели.

В шаблоне MVP Dolphin Smalltalk роль перехвата пользовательского ввода была перенесена в представление. Это фактически устранило первоначальную потребность в Контроллерах или Взаимодействиях в целом.

Таким образом MVP Dolphin Smalltalk MVP и Smalltalk-80 MVC могут казаться очень похожими на поверхности, но на самом деле, как я уже упомянул выше, Презентаторы и Контроллеры отличаются в своих основных задачах.

Создатель Кракена или Шаблоны Фаулера

2006 год. В ходе своего исследования и подготовки материала для будущей книги Мартин Фаулер вводит новые интерпретации Dolphin Model-View-Presenter — это Supervising Controller/Presenter и Passive View.

Основная мотивация Фаулера — это улучшение автоматизированного тестирования. Дело в том, что в то время было сложно автоматизировать тестирование представления, которое напрямую взаимодействует с моделью.

Тестировать UI-компоненты и виджеты было достаточно экзотическим занятием. Писать модульные тесты не представлялось возможности, так как не было среды, где можно было бы раздельно эмулировать конкретный элемент графического интерфейса. Можно было писать функциональные тесты, используя скрипты на подобие Autoit, но, как я уже сказал, это была экзотика.

В разработке web-приложений автоматизация была вообще отдельной темой. Это сейчас есть понятие Web Component и куча инструментов позволяющих покрыть его тестами вдоль и поперек. Я познакомился с Selenium RC (1.0) только аж в 2011 году, и даже тогда, тестирование rich client было достаточно непростым занятием.

Новые интерпретации Фаулера были призваны облегчить этот процесс.

Из названий становится ясна суть концепций. Контроллер или Презентатор должен был взять на себя обязанности представления в части наблюдения за определенными виджетами, реагирования на манипулирование этими виджетами и изменение модели на основе этих манипуляций.

Представление должно было стать пассивным. Оно просто отображало данные, но не содержало никакой логики. Связь представления с моделью была разорвана.

Таким образом разработчики могли сфокусироваться на тестировании функций Контроллера/Презентатора, проверке бизнес-логики через вызовы именно его функций и забыть о GUI элементах.

(martinfowler.com)

Это тот самый момент, когда Контроллер/Презентатор стал находится между компонентами Модели и Представления, он начал представлять из себя центральный диспетчер триады или просто… Кракена?

Именно эту реализацию вы найдете в Apple Cocoa API.

Именно эта реализация воплотилась в жизнь в популярных инструментах клиентской разработки. К этому моменту клиент web-приложения стал “толстым” (или “богатым”, кому что нравится). Появилась необходимость применять SoC и на этом уровне системы. На вооружения были взяты трендовые концепции того времени. Яркий пример это фреймворки ExtJS, Spine.js и Backbone.js

В этих инструментах представление абсолютно пассивно, просто структура JSON и HTML соответственно. И вся логика по обработке пользовательского ввода, бизнес на клиентской стороне, все пишется в Контроллере/Презентаторе.

При чем библиотеки вводят понятие Controller, это четко определенный компонент (в Backbone.js вы его не найдете, он был переименован в Router), в тоже время в названиях мелькает аббревиатура MVP.

Это точка отсчета, это зарождение концепции MVO, которая начинает гулять под названиями MVC/MVP внося хаос в мысли и сердца клиентских разработчиков.

Model-View-Adapter

Название часто используют применительно к концепции используемой в Apple Cocoa, когда Контроллер из себя представляет реализацию конкретного шаблона проектирования — Медиатор (Mediator) или Стратегия (Strategy).

Oracle, в своем блоге, подобную связку окрестила Mediating-Controller MVC. По сути это все тот же Кракен.

(developer.apple.com)

Presentation-Abstraction-Control (PAC)

Вызовем в этом месте оператор goto и вернемся обратно в 1987 год. Для истории это важно и ценно. На самом деле в этом году появилась, параллельно MVC, другая архитектурная концепция. Это альтернативный SoC, который делает акцент на иерархичности приложения. Концепция по своему устройству очень напоминает Кракена, описанного выше.

Концепцию разработал Йоель Кутаз, описание можно найти в работе под названием “PAC, an Object Oriented Model for Dialog Design”.

Presentation-Abstraction-Control — это архитектура, которая отделяет проблемы приложения в иерархии взаимодействующих компонентов, каждый из которых состоит из Презентации (тоже самое, что Представление), Абстракции (это что-то вроде Application Model, упоминавшейся выше) и Контрол (Кракен). Шаблон PAC предназначен для декомпозиции приложения в иерархию абстракций и для создания согласованной структуры, которая призвана облегчить проектирование пользовательских интерфейсов.

Описываемая концепция опосредованно или напрямую была связана с целым пластом других архитектурных стилей, таких как Seeheim, Arch Model, Amodeus-2, PAC-Amodeus и PAC *. Они не имеют отношения к Кракену, за тем я их просто упомяну для полноты картины.

Hierarchical Model–View–Controller

Другим примером, заслуживающим внимания, является шаблон иерархической MVC. Не являясь прямым производным семейства паттернов РАС, паттерн HMVC часто ассоциируется с PAC из-за его сходства.

Концепция HMVC была впервые описана в статье, появившейся в журнале JavaWorld Magazine в июле 2000 года.

(JavaWorld Magazine)

Разработанная Джейсоном Каем, Ранджит Капилой и Гауравом Палом, архитектурная концепция HMVC является предписанием для организации триад Model-View-Controller в иерархию для организации презентационного уровня “богатого” клиентского приложения, такого как Java Swing-приложения.

Хотя организация триад MVC в иерархию и похожа на PAC, она отличается тем, что компоненты Model и View поддерживают те же отношения наблюдателей, что и в MVC, и более того, что они направлены только на адрес представления слоя приложения, а не на адресацию всей архитектуры приложения. Контроллеры в HMVC описываются как выполняющие посредническую роль в триаде, подобно подходу Supervising Controller. Представления получают начальные события, сгенерированные пользователем, и определяют, какие действия делегировать контроллеру. По этой причине шаблон HMVC более похож на шаблон MVP для Dolphin, чем на исходный шаблон Model-View-Controller или Presentation-Abstraction-Control.

Model-View-ViewModel

Мы возвращаемся в 2000-е. И снова обратимся к статье Мартина Фаулера, которая описывает альтернативу концепциям Supervising Controller/Presenter и Passive View.

Этот новый подход ничто иное как более расширенный термин Application Model из Visual Works Smalltalk, который неоднократно мелькал в тексте ранее.

Фаулер дает этому подходу новое имя — Presentation Model.

В своей сути это замена для центрального компонента триады MVC Контроллера/Презентатора. Это абстракция, которая адаптирует данные модели предметной области к представлению, учитывая особенности этого представления.

(martinfowler.com)

Подобный подход удобен в системах, где представление можно определять как шаблон, который необходимо связать с определенными отображаемыми данными. Спустя год после публикации Фаулера, Джон Госсман презентует на базе описанной концепции, новый шаблон Model-View-ViewModel, как основу платформ разработки Windows Presentation Foundation и Silverlight.

(msdn.microsoft.com)

Слой ViewModel представляет из себя триаду компонентов.

Уже ранее упоминавшееся Модель Приложения (Application / Presentation Model). Это ничто иное, как адаптированные данные домена к конкретному представлению нашего приложения, учитывая различные побочные свойства представления, такие как цвет виджетов, состояние меню, заголовки и т.д.

Шаблон (Template) это то, на базе чего будет порождено новое представление. В качестве шаблонов WPF использует XAML.

Компоновщик данных (Data Binder) — это компонент, который, по сути, должна предоставлять сама платформа разработки, связывает Шаблон и Модель Приложения, порождая новое представление.

(Model-View-ViewModel)

И тут целая череда инструментов из клиентской разработки, которая прекрасно отражает эту концепцию в действии. В клиентской разработке начинается период, где на троне трендов начинает восседать декларативное программирование. Начинают активно использовать кастомные тэги и атрибуты HTML (хотя идея не нова и живет еще с JSP/JSF/XML).

Самый классический, наверное, пример это Knockout.js и его data-bind появившийся стараниями Стива Сандерсона в 2010 году. Ember.js с его популярным шаблонизатором Handlebars и, наконец, Angular.js с ng-model.

Model-View-Whatever

Об Angular.js надо упомянуть отдельно, так как этот инструмент ввел новую аббревиатуру, очень схожую с MVO. В разное время этот фреймворк прибегал к использованию разных сочетаний букв, он именовал себя MVC-фреймворк, MVVM-фреймворк и в конечном счете остановился на Model-View-Whatever.

Поощряя декларативное программирование и имея неявный механизм связывания данных (в том числе этот механизм может быть двухсторонний) с шаблоном, Angular.js вводит достаточно четкое понятие Контроллера. Это полноценный объект системы с соответствующим названием. Эту “кашу” дополняет отсутствие четко определенного слоя Модели, вместо него вводятся понятия Service и Factory.

Также вводится понятие триадной иерархии $rootScope -> $scope (это связь ViewModel в Angular.js), что притягивает “за уши” сюда HMVC и PAC.

Подобное богатство системных компонентов и возможностей развязывает руки клиентскому разработчику, слово Whatever появляется само собой, так как используя данный инструмент можно реализовать любую концепцию. Отсутствие рамок приводит к написанию страшнейших чудовищ, которые вырастают из Кракена.

(Model-View-Whatever)

Мое мнение, что именно с Angular, большинство разработчиков увязло в своих же смоляных ямах. Если бы была такая статистика, то она показала бы это.

К подобному гибридному смешению начинают стремится и другие популярные инструменты, к примеру, Backbone.js обзавелся Backbone.ViewModel и Backbone.ModelBinding.

В заключение

Заметка выглядит как очередная статья, описывающая весь зоопарк архитектурных шаблонов через призму времени.

Большинство текста — это моя вольная интерпретация, так как я не работал со Smalltalk, то я могу высказывать какие-то суждения, только на основе документов содержащих чужие мысли. Но в своей заметке я старался обращаться исключительно только к оригинальным документам и диаграммам, описывающим каждый шаблон.

На самом деле, я призываю к тому, чтобы читатель самостоятельно изучил эти документы и выстроил свою картину и мнение. Все ссылки я приведу ниже.

Я же выкатил этот Braindump, как что-то промежуточное между остальными своими мыслями.

Кракен — это не шаблон, это скорее анти-шаблон, архитектурный анти-стиль, это то, во что может превратиться любая из вышеописанных концепций, он сродни Callback Hell или Магическим Числам.

Так, а как же относится к Flux? Об этом в следующей заметке.

P. S. Пишите свои мысли на тему artur.basak.devingrodno@gmail.com

2017

Читайте продолжение:

Ссылки

+ Applications Programming in Smalltalk-80 (TM):How to use MVC, S. Burbeck

+ MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java, M.Potel

+ Twisting The Triad: The evolution of the Dolphin Smalltalk MVP

+ Delfin EC Overviews — MVP

+ Passive View — M. Fowler

+ SupervisingPresenter — M.Fowler

+ PresentationModel — M. Fowler

+ PAC, an Object Oriented Model for Dialog Design, J.Coutaz

+ HMVC: The layered pattern for developing strong client tiers, JavaWorld

+ Introduction to Model/View/ViewModel pattern for building WPF, J.Gossman

+ Apple Cocoa MVC (MVA)

+ Sun’s mediating-controller MVC

+ JSP Specification 1.0

+ Understanding JSP Model 2, JavaWorld

+ Interactive Application Architecture Patterns, D.Greer