Простая модель данных

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

'role'  => ['master', 'admin']

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

Или другой, более показательный пример

'content-type'  => 'application/json',

        'allowed'       => 'POST',

        'nologin'       => 1

Логиниться нет смысла, т/к ответ для поисковой подсказки в json и должен отдаваться любому пользователю без разницы авторизован он или нет. Плюс, метод POST и application/json предполагают проверку токена. Т.е варианты. А если учесть специфичных клиентов, типа обмен 1С, где свой механизм авторизации и никакие другие токены/куки не нужны ...

В общем, гораздо проще разрулить все это роутингом похожим на традиционный. На самом раннем этапе, чтобы лишних телодвижений не делать:)

Там фантазия только нужна, например имеем урлы

/sec1/sec2/sec3

/sec1/sec2/sec4

/sec1/sec5/sec6

, в /sec1/sec2 определен другой шаблон для документа, а в /sec1 слайдер(баннер/еще там чего), с флагом наследовать. И все документы по цепочке урла имеющие их парентом, автоматически получают все это. Соответственно, если не имеют свои значения для этих параметров.

Так что, на мой взгляд, есть как плюсы. Очевидные, что бы использовать это. Но и минусы, тоже есть. Как и у любой вещи.

В umi.cms архитектура построена так (упрощенно):

Там есть модуль, каждый модуль добавляет типы данных (может и не добавлять), пользователь может создать объект только определённого (доступного) типа. При запросе урла, контроллер находит объект, смотрит какой у него тип и отдаёт объект на обработку модулю. Тип по сути представляет из себя модуль и экшен.

Но там есть ещё протоколы, через которые можно дернуть какой то другой метод (макрос) модуля без объекта данных. В целом удобно, но есть и свои минусы в такой архитектуре.