Шаблон MVC — это тупик для разработки приложений?

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

В самом Model View Controller шаблоне нет ничего плохого. Он решает ту проблему, для которой его придумали — это разделение логики обработки запроса пользователя от логики представления информации.

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

Использование MVC шаблона хорошо там, где модули относительно независимы друг от друга. Например, они вызываются из главного меню. Пользователь работает с модулем A, потом открывает модуль B и так далее.

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

Также если поменялся процесс работы с системой (изменилась бизнес или доменная модель), то пользователь может обучиться новому процессу без внесения изменений в пользовательский интерфейс системы.

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

А что если система поставляется множеству пользователей?

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

Но здесь кроется коварство использования MVC шаблона. Как показано на изображении ниже, велик соблазн ссылаться напрямую с представления (View) модуля 'A' на контроллер (Controller) модуля 'B', с модуля 'B' на модуль 'C', с модуля 'C' на модуль 'D'.

(Или же из контроллера модуля 'A' на контроллер модуля 'B'. Или, что ещё хуже, из контроллера модуля 'A' на представление модуля 'B'. )

Бизнес процесс будет жёстко прошит в 3х представлениях (Views). Согласитесь, что не очень-то и наглядно. Изменение бизнес процесса будет также затруднено из-за распределения связей по нескольким файлам. А поддержку нескольких вариантов бизнес логики, где будут, например, связаны модули A, С и D, придется реализовывать через if/else в представлениях (Views).

К сожалению, данный подход очень часто используется для построения приложений.

Как же вернуть былую слабую связанность модулей системы, сохранив описание бизнес процессов внутри неё?

Для этого нужно вынести конфигурацию бизнес процессов из модулей и поместить её отдельно.
Сделать так, чтобы пользователи и все модули общались через один основной контроллер.
При этом контроллер будет руководствоваться конфигурацией, какие модули, в какой последовательности предоставлять пользователю для работы.

Для конфигурации состояний модулей и переходов между ними очень удобно использовать реализации, основанные на конечных автоматах ^[1] (Finite State Machine ^[2]).

Примерами таких реализаций в Java мире могут послужить:

• Spring Web Flow ^[3] — надстройка над Spring MVC ^[4].

• ADF Task Flows ^[5] от Oracle ^[6] — реализация очень похожа на Spring Web Flow.

• Lexaden Web Flow ^[7] — реализация для компонентной модели Vaadin ^[8].

Какие вы ещё знаете реализации данного подхода в Java?
Может, есть похожие фреймворки для других языков программирования?

Автор: hitmark

Источник ^[9]