Проектирование расширяемых модулей приложения
Добавлено: 2014.05.16, 14:53
Здравствуйте.
Давайте попробуем суммировать варианты каким образом в 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 можно "изменять в зависимости от потребностей" уже готовые компоненты сайта.
Пусть сайт структурно состоит из набора БазовыхМодулей (включенных или отключенных из админки)
В общем вот эта вся задача написания дополнительного кода, который расширит/изменит функционирование БазовогоМодуля.
БазовыйМодуль естественно не меняется, т.к. он общераспространенный и обновляемый через 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.