Фреймворк для архитектуры

Question

Я хочу попросить идею для создания плагинов / компонентов в веб-фреймворке (cms), таком как wordpress.

Я прошу концептуальную идею, а не код.

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

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

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

Например, если у меня есть компонент Seo, который добавляет некоторые поля панели администратора для управления мета-тегами для каждой страницы.

Если плагин Seo добавляет поля в «Страницы»Панель администратора и другие плагины добавляют еще поля, как я могу убедиться, что поля в некотором порядке для проверки.

С другой стороны, если я плагины добавить новые секции панели, это может быть сложнее управлять - яследует создать страницу, затем перейти в другой раздел и управлять там тэгами seo - больше времени для создания страниц.

Для меня, если Seo действительно плагин, он долженбыть отключенным / деинсталлированным / включенным отдельно от других плагинов.

Также, если какой-то другой плагин зависит от плагина Seo - действительно ли плагин Seo является плагином.

Потому что, если удалить его - другой код, который зависит от плагина Seo, сломается.

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

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

Если у меня есть плагин Authenticate (для обработки логики входа / выхода), код будет повсюду, и я не могу просто «отключить» егои так далее.

Спасибо

Answer 1

Я постараюсь поделиться своими мыслями в общем, потом дам более конкретные ответы.

Прежде всего, все плагины должны иметь тот же дизайн, что и код, например. Вы должны определить свои собственные интерфейсы и lib для сборки плагинов. Сами плагины должны быть слабо связаны и не зависеть между плагинами и компонентами ядра. Только основные компоненты (страницы) должны быть в состоянии расширяться - это плагины первого уровня - вы можете определить правила для загрузки определений сервисов из определенного каталога плагинов.

Интеграция между плагинами может быть достигнута с помощью шаблона проектирования Command - таким образом вы можете связать несколько плагинов и заставить их работать вместе.

Интеграция с основными компонентами может осуществляться с помощью внедрения зависимостей и шаблона нулевого объекта - способа обмена определениями служб с пустой реализацией - таким образом вы можете отключить вход / выход из системы.

Плагины также могут быть удалены - таким образом, вам нужно удалить все файлы плагинов. Исходя из этого требования, невозможно объединить основные компоненты и плагины - основные компоненты должны знать, где нужно искать файлы служб (определения контейнеров), загружать их и показывать, что там когда-либо есть. Если вы удалите файлы плагинов - основные компоненты должны продолжать существовать.

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

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

В целом цель состоит в том, чтобы избавиться от операторов if, слабосвязанного кода и простого способа интеграции плагинов с основными компонентами и цепными плагинами.