Вы, простите, сценарии использования не пробовали описывать и реализовывать?
Пробовал и реализовывал, но это почему-то не привело к пониманию, как можно построить навигацию для большого приложения.
Эта технология не исключает использование сценариев при построении систем, а дополняет их, позволяя удобно организовать административную часть приложения.
В то же время ничего не мешает реализовывать сценарии в отдельный модулях, которые отличаются от CRUD моделей.
Пользовательский интерфейс в статье был использован для того, чтобы подвести к тому самому модельному слою, о котором вы упоминаете. В нашем случае модель приложения динамическая и она определяется в XML формате. За центральным контроллером стоит интерпретатор этой модели.
Самое важное, на наш взгляд — это то, что модель является асинхронной, основанной на событиях. В отличие, например, от модели приложения заданной на основе классов или созданной посредством кодогенерации из статической диаграммы.
Мы стремимся к тому, чтобы модель описанная с помощью Lexaden Web Flow, можно было повторно использовать для desktop, web, mobile, services и других приложений.
Технически это вполне можно сделать уже сейчас. Но на данном этапе мы не пытаемся объять необъятное. Поэтому сфокусировались лишь на проблеме адаптации приложения к разным рынкам и разным клиентам в рамках одной веб-платформы.
Как результат, модельный слой стал диктовать, как будет работать интерфейс приложения. При этом, на наш взгляд, улучшилось юзабилити системы, в частности навигация по модели приложения.
И это только часть тех выгод, которые можно получить, использовав эту технологию уже сейчас.
В какой-то мере у нас есть возможность не использовать целиком MVC триаду, а использовать типа ITask интерфейс. Но эту возможность нужно ещё хорошенько обдумать и проверить в боевых условиях в продакшане. :)
Для объяснения того, что мы предлагаем и как это связано с MVC и другими технологиями, будет отдельная статья.
Чтобы немного прояснить ситуацию, как пример, можно привести всем хорошо известный HTML. Это декларативный язык разметки веб страницы. Он задаёт, как компоненты между собой будут связаны для отображения информации браузером.
В нашем же случае Lexaden Web Flow используется для описания структуры/модели всего приложения, а не отдельной страницы. Модель эта интерпретируется специальным контроллером, аналогия с браузером.
Страницы, в нашем случае — это MVC триады, общаются с контроллером посредством событий, поэтому являются слабосвязанными. Они связываются между собой только на уровне описания модели приложения, привязываются к определённым нодам. Используется что-то вроде CSS, только на Java.
Это тесно связано с термином метапрограммирование . :) Когда программы создают сами себя.
Формы для сущностей системы могут быть большими. Поэтому операции для них выделены в отдельные MVC-триады. Также в системе используется одно центральное окно для отображения представлений. Мы отказались от всякого рода модальных и выскакивающих окон. Навигация по системе осуществляется через это окно. Breadcrumb компонент отображает на каком из представлений какой сущности находится пользователь.
Это позволило обеспечить единый интерфейс для пользователя навигации по системе и её функциям. Вместо альтернативы с кучей модальных окон перекрывающих друг друга. Или немодальных, в которых можно запутаться, как только перейдёшь за первый десяток.
Мой просчёт, как и в первоначальной статье, так и в этом комментарии я слишком быстро перескочил с примера из 4х модулей на огромную систему в сотни модулей.
В нашей системе модули представляют собой MVC-триады. Каждый из них отвечает за определённое элементарное действие. Например, за создание какой-либо сущности, другое за обновление, удаление или отображение списка сущностей. Также есть специализированные модули, которые могут выполнять сложную логику, например, составление расписания для медсестёр.
При этом переходы между контроллерами, т.е. модулями, можно реализовать по-разному. Как я понял из комментариев, каждый эту логику реализует по-своему. Очевидно, что в системе, состоящей из 4х модулей, как написано в моей первой статье, нету смысла выносить это в конфигурацию.
Да и многие используют сразу CRUD модули целиком, не разбивая их на элементарные операции.
Модули, т.е. MVC триады, в нашем случае участвуют в системе распределения прав, где определённые роли пользователей не могут получить доступ, например, к изменению сущностей, а просматривать информацию могут. Так мы можешь законфигурировать множество ролей и задать им свои уникальные профайлы, собранные из доступных этой роли модулей.
Наверное, всё-таки, пытаясь объяснить проблему и взяв MVC, я слишком издалека зашёл.
Вы правы в случае, когда визуализация не нужна, то нет необходимости выделять и создавать триаду MVC.
Тогда получится, что бизнес-сущности без визуализации и с ней (через контроллеры) могут взаимодействовать друг с другом напрямую.
Но представьте себе большую систему управления больницами. Также представьте то, что системой будут пользоваться множество больниц в рамках большинства европейский государств.
В каждой больнице бизнес-процессы и бизнес-модели могут существенно отличаться друг от друга, не говоря уже про различия на уровне государств.
Монолитная система со множеством настроек тут и там не позволит учесть все требования и в приемлемое время вносить изменения. Процесс изменений может растягиваться на месяцы, а то и на годы.
Вероятность появления ошибок в системе будет возрастать по мере того, как система будет эволюционировать. Если серьёзная ошибка в финансовом ПО приведёт к потере денег, то к чему может привести ошибка в медицинском ПО?
Решение же описанное в первой статье позволяет собирать приложение под каждого клиента отдельно из повторно используемых модулей. Модули же можно юнит-тестировать. И убедиться, что они работают так как нужно.
Так как каждый клиент получает своё уникальное приложение, то это уменьшает вероятность появления ошибок на порядки.
Перечитал ещё раз внимательней вашу статью. Как я понял, вы делали акцент в статье на Контроллер, какую роль он играет в MVC и как лучше его использовать, чтобы разделить Модель и Представление.
В моей статье я больше делал акцент на Представление и сравнивал его реализации в MVC и MVP. И как мне кажется, мне удалось показать общие моменты этих двух парадигм относительно Представления.
Роль Контроллера я не затрагивал, так как, по моему мнению, эта тема слишком обширна, чтобы рассказать о ней в рамках статьи.
Ваша же статья вполне может служить основой для понимания роли Контроллера в MVC.
Как это сделать? Пример можно?
описывающее подробно возможный вариант выхода MVC из тупика:
Навигация: вариант реализации для корпоративного приложения
Пробовал и реализовывал, но это почему-то не привело к пониманию, как можно построить навигацию для большого приложения.
Эта технология не исключает использование сценариев при построении систем, а дополняет их, позволяя удобно организовать административную часть приложения.
В то же время ничего не мешает реализовывать сценарии в отдельный модулях, которые отличаются от CRUD моделей.
Самое важное, на наш взгляд — это то, что модель является асинхронной, основанной на событиях. В отличие, например, от модели приложения заданной на основе классов или созданной посредством кодогенерации из статической диаграммы.
Мы стремимся к тому, чтобы модель описанная с помощью Lexaden Web Flow, можно было повторно использовать для desktop, web, mobile, services и других приложений.
Технически это вполне можно сделать уже сейчас. Но на данном этапе мы не пытаемся объять необъятное. Поэтому сфокусировались лишь на проблеме адаптации приложения к разным рынкам и разным клиентам в рамках одной веб-платформы.
Как результат, модельный слой стал диктовать, как будет работать интерфейс приложения. При этом, на наш взгляд, улучшилось юзабилити системы, в частности навигация по модели приложения.
И это только часть тех выгод, которые можно получить, использовав эту технологию уже сейчас.
В какой-то мере у нас есть возможность не использовать целиком MVC триаду, а использовать типа ITask интерфейс. Но эту возможность нужно ещё хорошенько обдумать и проверить в боевых условиях в продакшане. :)
Видимо так и происходит.
Впредь, буду тщательней выбирать аналогии и термины.
Спасибо. :)
Для объяснения того, что мы предлагаем и как это связано с MVC и другими технологиями, будет отдельная статья.
Чтобы немного прояснить ситуацию, как пример, можно привести всем хорошо известный HTML. Это декларативный язык разметки веб страницы. Он задаёт, как компоненты между собой будут связаны для отображения информации браузером.
В нашем же случае Lexaden Web Flow используется для описания структуры/модели всего приложения, а не отдельной страницы. Модель эта интерпретируется специальным контроллером, аналогия с браузером.
Страницы, в нашем случае — это MVC триады, общаются с контроллером посредством событий, поэтому являются слабосвязанными. Они связываются между собой только на уровне описания модели приложения, привязываются к определённым нодам. Используется что-то вроде CSS, только на Java.
Это тесно связано с термином метапрограммирование . :) Когда программы создают сами себя.
Есть книжки по этой теме Фабрики разработки прогам, Порождающее программирование.
Тема достаточно обширная. Поэтому вижу смысл в написании нескольких статей с примерами кода.
Это позволило обеспечить единый интерфейс для пользователя навигации по системе и её функциям. Вместо альтернативы с кучей модальных окон перекрывающих друг друга. Или немодальных, в которых можно запутаться, как только перейдёшь за первый десяток.
У нас права и модули развязаны на уровне метаданных. Так что каши никакой нету. И нету нарушения SRP.
Чтобы управлять профайлами в едином стиле в конфигурации. Вплоть до элементарных действий, которые может осуществить пользователь определённой роли.
На наш взгляд, получилось весьма удобно.
В нашей системе модули представляют собой MVC-триады. Каждый из них отвечает за определённое элементарное действие. Например, за создание какой-либо сущности, другое за обновление, удаление или отображение списка сущностей. Также есть специализированные модули, которые могут выполнять сложную логику, например, составление расписания для медсестёр.
При этом переходы между контроллерами, т.е. модулями, можно реализовать по-разному. Как я понял из комментариев, каждый эту логику реализует по-своему. Очевидно, что в системе, состоящей из 4х модулей, как написано в моей первой статье, нету смысла выносить это в конфигурацию.
Да и многие используют сразу CRUD модули целиком, не разбивая их на элементарные операции.
Модули, т.е. MVC триады, в нашем случае участвуют в системе распределения прав, где определённые роли пользователей не могут получить доступ, например, к изменению сущностей, а просматривать информацию могут. Так мы можешь законфигурировать множество ролей и задать им свои уникальные профайлы, собранные из доступных этой роли модулей.
Наверное, всё-таки, пытаясь объяснить проблему и взяв MVC, я слишком издалека зашёл.
Тогда получится, что бизнес-сущности без визуализации и с ней (через контроллеры) могут взаимодействовать друг с другом напрямую.
Но представьте себе большую систему управления больницами. Также представьте то, что системой будут пользоваться множество больниц в рамках большинства европейский государств.
В каждой больнице бизнес-процессы и бизнес-модели могут существенно отличаться друг от друга, не говоря уже про различия на уровне государств.
Монолитная система со множеством настроек тут и там не позволит учесть все требования и в приемлемое время вносить изменения. Процесс изменений может растягиваться на месяцы, а то и на годы.
Вероятность появления ошибок в системе будет возрастать по мере того, как система будет эволюционировать. Если серьёзная ошибка в финансовом ПО приведёт к потере денег, то к чему может привести ошибка в медицинском ПО?
Решение же описанное в первой статье позволяет собирать приложение под каждого клиента отдельно из повторно используемых модулей. Модули же можно юнит-тестировать. И убедиться, что они работают так как нужно.
Так как каждый клиент получает своё уникальное приложение, то это уменьшает вероятность появления ошибок на порядки.
Так, что мы как бы решаем немного разные задачи.
В моей статье я больше делал акцент на Представление и сравнивал его реализации в MVC и MVP. И как мне кажется, мне удалось показать общие моменты этих двух парадигм относительно Представления.
Роль Контроллера я не затрагивал, так как, по моему мнению, эта тема слишком обширна, чтобы рассказать о ней в рамках статьи.
Ваша же статья вполне может служить основой для понимания роли Контроллера в MVC.