Какое отношение к бизнес-логике имеет, например, мастер создания пользователя?
Если рассмотреть мастер создания пользователя, как многошаговый процесс разнесённый во времени, то бизнес логика в этом случае будет распределена по разным компонентам. И атомарное действие будет осуществляться в рамках действия этого процесса.
Предметную область количественно оценить достаточно сложно.
Из призмы моего опыта работы над крупными проектами такими, как система администрирования школ для американского рынка и системы управления медицинскими препаратами в госпиталях, могу сказать, что количественно оценить предметную область по базе данных вполне возможно.
Сделайте отдельный контрол
По сути так и получилось. Сделали одну страницу, как контрол и используем её повторно.
Про UserRole согласен. Нужно переделать в виде редактируемой кросс таблицы, чтобы было наглядно и удобно управлять ролями.
Спасибо, за отличный фидбак! Очевидно, что опытных разработчиков/архитекторов, как вы, сложно удивить такой демкой.
Технология, которую мы используем сейчас только набирает обороты. Её активно начинают использовать в крупных банках и других крупных организациях, где требования меняются быстрее, чем меняется приложение.
Демка, очевидно, не такая впечатляющая, потому что в ней не показаны другие аспекты использования технологии. Такие, как разработка, юнит тестирование, анализ и проектирование, юзабили системы и что самое главное — это поддержка системы в продакшане, когда требования меняются и нужно адаптировать систему под них.
Будем развивать это направление дальше, учитывая конструктивный фидбак от хабражителей :)
Извиняюсь, заголовок не в полной мере отражает содержание статьи.
Попробую немного равзёрнуто ответить здесь в комментарии.
Суть статьи в том, что MVC и MVP парадигмы были придуманы для того, чтобы Представления не зависили от Контроллеров.
Так как MVC парадигма достаточно известна, то многие фреймворки используют эту абривиатуру для продвижения себя.
И создаётся ложное впечатление, что на MVC/MVP фреймворке можно сделать достаточно легко приложения разной степени сложности.
Но на практике всё выходит немного не так, как ожидается. И в каждом MVC/MVP фреймворке проблемы связанности контроллеров решаются по-разному. Это то их и отличает.
Вы можете спросить, а зачем повторно использовать Контроллеры?
В больших приложениях это бывает достаточно часто, когда, например, нужно несколько Update экранов выстроить в связанный визард или использовать таблицу с сортировкой, фильтрами, как удобный способ выбора значений для формы, т.к. в комбобокс не получается запихнуть несколько тысяч записей.
Поэтому проблема повторного использования контроллеров и существует. Каждый фреймворк решает это по-своему.
Для небольших приложений с небольшой предметной областью, видимо, проблемы то и нету. Но для приложений, где доменная модель состоит из сотен таблиц, проблема очень даже есть.
Контроллер — всего лишь соединительный элемент.
Да, но в больших проектах контроллеры напару с вюхами приходится повторно использовать. Например, почему бы не использовать навороченную логику грида с сортировкой, фильтрацией и другими плюшками для выбора значений. Своего рода продвинутый комбобокс, только на отдельной странице.
Да, частично программирование уйдёт туда. К этому стремятся многие приверженцы Business Process Management (BPM) систем.
Но BPM годится только для организации бизнес процессов между приложениями. И их использование внутри одной системы не очень оправдано.
Плюс BPM системы основаны на спецификациях, что налагает некоторые ограничения. Например, они перегружены разными деталями привязки к данным, создания переменных и д.р. вещами, которые усложняют конфигурацию.
Почему бы не вынести бизнес процессы внутри одного приложения в конфигурацию? Это позволит легче понимать бизнес процессы не программистам, например, бизнес или функциональным аналитикам, продукт или проджект менеджерам.
Они смогут тогда общаться на одном общем языке. Не об этом ли они мечтают?
Сложно в комментариях показать все варианты использования конфигураций приложения.
За реализацией, например, Lexaden Web Flow (LWF) стоит не просто Statemachine, а Statechart с реализацией иерахий состояний. Плюс реализовано наследование и полиморфизм для них, что облегчает повторное использование частей конфигурации.
Например, бизнес логика переходов CRUD компонентов определена отдельно и повторно используется во вмногих модулях системы.
Примеры конфигураций для разных компонентов можно посмотреть на Enterprise Sampler.
Если текущий экран предполагает, что с него я могу попасть только в Б или С, то хоть убейся — от этих ссылок ты никуда не уйдёшь, это часть интерфейса.
С текущего экрана можно попасть на экраны Б или С, если в root контроллер отправлять не прямую связь с модулем Б или С, а событие. Например в визардах есть кнопка Next. Она может отправлять событие «next», которое, согласно конфигурации в отдельном файле, скажет системе показать пользователю экран Б. При этом все экраны могут отправлять события «next», «prev», «cancel», а порядок их переходов определять в конфигурации.
На самом деле MVC виноват в том, что за деталями не видно сути вещей.
Думая в терминах Модели, Представления, Контроллера очень легко связать разные модули системы в тесносплетённый клубок. Тем самым, повторное использование модулей будет затруднено и сама система превратится в один большой монолитный модуль.
Пример из жизни:
Eсть CMS + Управление проектами.
CMS — это один блок. Управление проектами — второй.
При этом, заказчик хочет привязать проект к клиенту, но т.к. это различные блоки, сделать это невозможно.
В статье я пытался рассказать, как можно организовать архитектуру внутри одного приложения.
В вашем же случае, вы хотите связать функционал двух приложений (или независимых модулей).
Для решения таких задач существуют отдельные фреймворки, например, Spring Integration для Java. Где создаётся интеграционный посредник, который связывает функционал двух или более приложений или модулей системы.
На самом деле в статье я хотел показать разные степени связанности между MVC и бизнес-логикой. К чему это приводит, и как можно вынести бизнес-логику из UI.
Если рассмотреть мастер создания пользователя, как многошаговый процесс разнесённый во времени, то бизнес логика в этом случае будет распределена по разным компонентам. И атомарное действие будет осуществляться в рамках действия этого процесса.
Из призмы моего опыта работы над крупными проектами такими, как система администрирования школ для американского рынка и системы управления медицинскими препаратами в госпиталях, могу сказать, что количественно оценить предметную область по базе данных вполне возможно.
По сути так и получилось. Сделали одну страницу, как контрол и используем её повторно.
Спасибо, за отличный фидбак! Очевидно, что опытных разработчиков/архитекторов, как вы, сложно удивить такой демкой.
Технология, которую мы используем сейчас только набирает обороты. Её активно начинают использовать в крупных банках и других крупных организациях, где требования меняются быстрее, чем меняется приложение.
Демка, очевидно, не такая впечатляющая, потому что в ней не показаны другие аспекты использования технологии. Такие, как разработка, юнит тестирование, анализ и проектирование, юзабили системы и что самое главное — это поддержка системы в продакшане, когда требования меняются и нужно адаптировать систему под них.
Будем развивать это направление дальше, учитывая конструктивный фидбак от хабражителей :)
Но мы пытаемся смотреть смотреть на всё приложение, как на большой визард.
Как бы вы релизовали такую логику приложения, как на этих видео?
www.youtube.com/watch?v=w59cb0gYFRI
www.youtube.com/watch?v=zTjHcLG35Gs
Попробую немного равзёрнуто ответить здесь в комментарии.
Суть статьи в том, что MVC и MVP парадигмы были придуманы для того, чтобы Представления не зависили от Контроллеров.
Так как MVC парадигма достаточно известна, то многие фреймворки используют эту абривиатуру для продвижения себя.
И создаётся ложное впечатление, что на MVC/MVP фреймворке можно сделать достаточно легко приложения разной степени сложности.
Но на практике всё выходит немного не так, как ожидается. И в каждом MVC/MVP фреймворке проблемы связанности контроллеров решаются по-разному. Это то их и отличает.
Вы можете спросить, а зачем повторно использовать Контроллеры?
В больших приложениях это бывает достаточно часто, когда, например, нужно несколько Update экранов выстроить в связанный визард или использовать таблицу с сортировкой, фильтрами, как удобный способ выбора значений для формы, т.к. в комбобокс не получается запихнуть несколько тысяч записей.
Поэтому проблема повторного использования контроллеров и существует. Каждый фреймворк решает это по-своему.
Для небольших приложений с небольшой предметной областью, видимо, проблемы то и нету. Но для приложений, где доменная модель состоит из сотен таблиц, проблема очень даже есть.
Да, но в больших проектах контроллеры напару с вюхами приходится повторно использовать. Например, почему бы не использовать навороченную логику грида с сортировкой, фильтрацией и другими плюшками для выбора значений. Своего рода продвинутый комбобокс, только на отдельной странице.
Хотя, статью можно было бы и не читать.
Достаточно былы бы картинки посмотреть, кроме последней. ;)
Его принцип прослеживается во многих паттернах.
Мне, например, легче применять один основной принцип, чем пытаться оперировать целой кучей шаблонов.
Но BPM годится только для организации бизнес процессов между приложениями. И их использование внутри одной системы не очень оправдано.
Плюс BPM системы основаны на спецификациях, что налагает некоторые ограничения. Например, они перегружены разными деталями привязки к данным, создания переменных и д.р. вещами, которые усложняют конфигурацию.
Почему бы не вынести бизнес процессы внутри одного приложения в конфигурацию? Это позволит легче понимать бизнес процессы не программистам, например, бизнес или функциональным аналитикам, продукт или проджект менеджерам.
Они смогут тогда общаться на одном общем языке. Не об этом ли они мечтают?
Сложно в комментариях показать все варианты использования конфигураций приложения.
За реализацией, например, Lexaden Web Flow (LWF) стоит не просто Statemachine, а Statechart с реализацией иерахий состояний. Плюс реализовано наследование и полиморфизм для них, что облегчает повторное использование частей конфигурации.
Например, бизнес логика переходов CRUD компонентов определена отдельно и повторно используется во вмногих модулях системы.
Примеры конфигураций для разных компонентов можно посмотреть на Enterprise Sampler.
С текущего экрана можно попасть на экраны Б или С, если в root контроллер отправлять не прямую связь с модулем Б или С, а событие. Например в визардах есть кнопка Next. Она может отправлять событие «next», которое, согласно конфигурации в отдельном файле, скажет системе показать пользователю экран Б. При этом все экраны могут отправлять события «next», «prev», «cancel», а порядок их переходов определять в конфигурации.
Пример кода:
Думая в терминах Модели, Представления, Контроллера очень легко связать разные модули системы в тесносплетённый клубок. Тем самым, повторное использование модулей будет затруднено и сама система превратится в один большой монолитный модуль.
В статье я пытался рассказать, как можно организовать архитектуру внутри одного приложения.
В вашем же случае, вы хотите связать функционал двух приложений (или независимых модулей).
Для решения таких задач существуют отдельные фреймворки, например, Spring Integration для Java. Где создаётся интеграционный посредник, который связывает функционал двух или более приложений или модулей системы.