Проектирование расширяемых модулей приложения

Общие вопросы по использованию второй версии фреймворка. Если не знаете как что-то сделать и это про Yii 2, вам сюда.
Ответить
Аватара пользователя
maleks
Сообщения: 1890
Зарегистрирован: 2012.12.26, 12:56

Проектирование расширяемых модулей приложения

Сообщение maleks »

Здравствуйте.
Давайте попробуем суммировать варианты каким образом в yii2 можно "изменять в зависимости от потребностей" уже готовые компоненты сайта.
Пусть сайт структурно состоит из набора БазовыхМодулей (включенных или отключенных из админки)
В общем вот эта вся задача написания дополнительного кода, который расширит/изменит функционирование БазовогоМодуля.
БазовыйМодуль естественно не меняется, т.к. он общераспространенный и обновляемый через composer.
Например в vendor/maleks/user есть модуль Пользователь, подключается приложением как обычно в конфиге.
Этот модуль Пользователь - это как бы общее решение, но например в конкретном случае мне нужно во многих случаях отличное поведение от предоставляемого.
(например реализация разных версий восстановления пароля, разных регистраций)
И собственно какими способами нужно писать БазовыйМодуль чтобы его легко можно было "натюнить" уже под конкретное ТЗ и конкретные методы "изменения поведения":

1) Пишем наследника для maleks\user и в конфиге используем его вместо предка. Ну это самое обычное решение.

2) Классы этого модуля можно через Yii::$classMap попереопределять. Но это мне кажется сильно уж топорное решение.

3) Можно для классов модуля изменить соответствие неймспейса - другой папке. Через Yii::setAlias().
Например некий контроллер у меня в maleks\user\controllers\admin\Controller, и я переназначаю:
Yii::setAlias('maleks\user\controllers\admin', некая другая папка) и там мой переопределенный контроллер

4) Использовать события. В ходе выполнения каких то процессов понатыкать вызов событий, и на сам изначальный объект эти события навешивать.

5) Использовать возможности mixin, когда функционал БазовогоМодуля частично завистит от реализации имплементированной
в методах объекта поведения, навешанного на него. И эти "поведения" через конфиг менять

6) Зацепиться на DI и интерфейсы в конструкторе.
Когда можно настраивая "соответствие" интерфейса классу менять реальный используемый класс.

7) С помощью методов 2) и 3) нормально будет дописывать если надо контроллеры для БазовогоМодуля? (дописывать в своем расширяющем модуле)

Что еще?


p.s. Кстати для пункта 2) это же не сильно страшно что уже не будет соответствия "путь - неймспейс"?
Например контроллер maleks\user\controllers\admin\Controller запихну в результате в папку app\controllers\maleks\user\controllers\admin\Controller.
Yii2 universal module sceleton - for basic and advanced templates

lancedevnull
Сообщения: 1268
Зарегистрирован: 2013.07.17, 17:37

Re: Проектирование расширяемых модулей приложения

Сообщение lancedevnull »

maleks писал(а): 1) ... Ну это самое обычное решение
но мы не ищем легких путей :lol:

Аватара пользователя
maleks
Сообщения: 1890
Зарегистрирован: 2012.12.26, 12:56

Re: Проектирование расширяемых модулей приложения

Сообщение maleks »

Вот еще из другой темы что нашлось:

8) Контроллеры можно переопределять через controllerMap модуля,

9) вьюхи переопределяются через темы,
Yii2 universal module sceleton - for basic and advanced templates


Аватара пользователя
chungachguk
Сообщения: 432
Зарегистрирован: 2012.07.17, 11:52

Re: Проектирование расширяемых модулей приложения

Сообщение chungachguk »

... и тигры у ног моих сели.

Мне кажется нужно как-то вопрос перефразировать, я, если честно, не понял какие проблемы ты пытаешься решить. Простым переопределением классов обычно дело ограничивается в Yii.

tar_m
Сообщения: 140
Зарегистрирован: 2012.12.26, 07:37

Re: Проектирование расширяемых модулей приложения

Сообщение tar_m »

У меня сейчас успешно работает система под названием External
Ну там у меня ряд интересных решений.
Смысл такой - External это слепые связи между модулями, почему слепые? потому что модуль запрашивая External не знает кто ему и в каком количестве вернется. Это позволяет логически расширят модули, с вполне предсказуемым функционалом и при этом оставлять логику самого модуля неизменным.

Как пример можно привести вывод информации на главной странице

Если коротко как это работает

Вначале регистратор собирает со всех модулей информацию о возможных Externals по типу

Код: Выделить всё

  
  public function registerExternals()
    {
    return [
        ['implement' => 'system', 'task' => 'management', 'class' => 'System',],
    ];
    }
Параметр

Код: Выделить всё

'class' => 'System'
Определяет класс который будет запущен после инициализации Externals в случае необходимости (/module/externals/ClassNameExternal)

После регистрации модуль может запросить в нужных местах классы внешних

Код: Выделить всё

    $this->Template->setTemplate('management');

    if ($this->Register->Externals->has('system', 'management'))
    {
        $externalArray = $this->Register->Externals->createAll('system', 'management');

        foreach ($externalArray as $value)
        {
        $value->renderGeneral();
        }
    }
По факту количество внешних может быть большое количество а значит модуль разрабатываясь должен предусматривать возможность бесконечного масштабирования, это занимает определенное время но результат реально доставляет.

У меня это очень часто применяется, это позволяет сделать задел на будущее и больше не возвращатся к старым модулям и модифицировать их.

Аватара пользователя
maleks
Сообщения: 1890
Зарегистрирован: 2012.12.26, 12:56

Re: Проектирование расширяемых модулей приложения

Сообщение maleks »

chungachguk писал(а): Мне кажется нужно как-то вопрос перефразировать, я, если честно, не понял какие проблемы ты пытаешься решить. Простым переопределением классов обычно дело ограничивается в Yii.
Есть например модуль в вендоре.
Чего я могу достичь тем что переопределю класс модуля на другой? Кроме того что контроллеры потеряются...
Для компонентов каких то то да, пойдет метод.
Yii2 universal module sceleton - for basic and advanced templates

Аватара пользователя
maleks
Сообщения: 1890
Зарегистрирован: 2012.12.26, 12:56

Re: Проектирование расширяемых модулей приложения

Сообщение maleks »

tar_m, это у вас типа такой системы хуков получается:
1) модули регистрируют какие то имена процессов
2) другие модули(которые включенные?) могут к данному процессу добавить свою инфу
3) модуль запрашивая данные получает их от всех модулей.

Это типа друпальной системы хуков, я думал над ней, просто насколько это все с ооп играет вопрос.
Я думал над похожим вариантом на уровне yii событий.
1) Модуль А регистрирует свои некоторые внешние доступные события
2) Другие модуля могут отмечать на какие события Модуля А они подписываются
3) В момент init() Модуля А выполняется действие когда подписанные на него модуля цепляют через ->on свои обработчики.

Это должен быть довольно мощный вариант, но по опыту у подобных хуковых штук есть проблемы с производительостью.
Yii2 universal module sceleton - for basic and advanced templates

Аватара пользователя
nizsheanez
Сообщения: 814
Зарегистрирован: 2011.04.29, 13:09
Откуда: Москва

Re: Проектирование расширяемых модулей приложения

Сообщение nizsheanez »

Подкину вам инфу для размышления.
Подумайте в сторону unix way.
Это когда вы делаете много-много простых элементов. А когда вам нужно сложное, вы не переопределяете и не усложняете простое, а собираете цепочку из простых элементов.

У PubSub есть онда большая проблема: ты смотришь в код и ты понятия не имеешь что будет выполняться после вызова события и в каком порядке.
ИМХО PubSub нужен для взаимодействия процессов или неблокирующих вызовов. Во всех остальных случаях, это привнесение хаоса в выполняющийся сверху вниз код.

Мое предложение - подумайте, можно ли вместо усложнения системных компонентов, сделать еще простых и собрать их в цепочку.

tar_m
Сообщения: 140
Зарегистрирован: 2012.12.26, 07:37

Re: Проектирование расширяемых модулей приложения

Сообщение tar_m »

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

Аватара пользователя
nizsheanez
Сообщения: 814
Зарегистрирован: 2011.04.29, 13:09
Откуда: Москва

Re: Проектирование расширяемых модулей приложения

Сообщение nizsheanez »

не всегда понятна полная цепочка компонентов
ну если не понятно в какой последовательности выполнять код, то вы его не сможете написать ни в каком виде

В том и весь смысл, вы перестаете думать полными цепочками, и начинаете делать маленькие детальки.
А когда появляется нужда: "Хочу вот такую цепочку" собираете ее. "А теперь хочу такую цепочку" - собираете вторую цепочку.

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

Ответить