Загвоздка в проектировании структуры модуля

[Prosto_Tok]

Здравствуйте! Имеется yii2 advancend
Планирую текущие работы переделывать на модули, т.к. уже проблематично искать нужный кусочек кода. Возник вопрос, как лучше всего объединить в модули мои работы.

На данный момент на frontend и backend имеются свои контроллеры и представления. Модели общие для всего проекта.
Если отбросить представления, то контроллеры у меня местами дублируют функционал.
Для примера:
Имеется возможность создавать/редактировать/удалять новости. Данная возможность есть, как во фронтеде, так и в бэкэнде за одним лишь исключением, что для фронтенд и бэкэнд идут свои права доступа к этим экшенам, но функционал один и тот же.

Как грамотнее всего объединить все мои работы в модули?

[andrei.obuhovski]

Создать общий и унаследоваться?

[Prosto_Tok]

Создать общий и унаследоваться?

Можно привести пример унаследования для разных модулей? Вопрос может быть и глупый, но я сейчас понимаю под наследованием указанием полного пути до контроллера модуля

[andrei.obuhovski]

NewsController extends common\modules\news\controllers\NewsController

[zelenin]

забудь о том, что тебе посоветовали. Делай общий модуль, который является бэкендом же, а фронт вообще к модулю не относится. Теперь поясню: модуль должен реюзабельным, переносимым в другой проект. Бэкенд будет везде одинаковый, а фронт проектозависим, поэтому в модуль его включать глупо.
И ни в коем случае не плодить дочерние модули.

[rugabarbo]

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

Реюзабельность и переносимость дорого обходится (особенно в поддержке) и не всем нужна.

[zelenin]

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

Реюзабельность и переносимость дорого обходится (особенно в поддержке) и не всем нужна.

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

[rugabarbo]

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

Реюзабельность и переносимость дорого обходится (особенно в поддержке) и не всем нужна.

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

Модуль не должен быть ни реюзабельным, ни переносимым.
Может быть.
Но не должен быть.

[lynicidn]

самодостаточная единица приложения может быть самодостаточной, но не обязана!

[zelenin]

Реюзабельность и переносимость дорого обходится (особенно в поддержке) и не всем нужна.

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

Модуль не должен быть ни реюзабельным, ни переносимым.
Может быть.
Но не должен быть.

подставь вместо модуль экстеншн. Может быть. Но не должен. Понимаешь аналогию? viewtopic.php?p=178383#p178383 хочешь делать просто - делай. хочешь делать качественно - приложи усилие.
Можно размазать логику, но зачем? Можно собрать всю логику в одном месте - удобнее. А главное делает модуль автоматом переносимым (но еще не совсем реюзабельным, поскольку в условиях yii это можно сделать только на простом уровне http://www.yiiframework.ru/forum/viewto ... 19&t=23349 )

[rugabarbo]

Я использую модули, но не выделяю их в расширения и не выкладываю в OS, потому что по времени не потяну их качественную поддержку. Считаю, что в этом случае их лучше вовсе не выкладывать.

В результате большая часть моих модулей не обладает переносимостью. А те, которые используются лишь в одном проекте, не обладают и реюзабельностью. Нет таких задач для этих модулей.

[zelenin]

Я использую модули, но не выделяю их в расширения и не выкладываю в OS, потому что по времени не потяну их качественную поддержку. Считаю, что в этом случае их лучше вовсе не выкладывать.

В результате большая часть моих модулей не обладает переносимостью. А те, которые используются лишь в одном проекте, не обладают и реюзабельностью. Нет таких задач для этих модулей.

ты не слышишь. не надо размазывать логику по проекту и любой модуль, не завязанный на другие модули, станет переносимым. Любой модуль, размазанный по проекту, автоматом становится не переносимым. Просто нет никакого объективного смысла размазывать.
Пример: абстрактный модуль пользователей.

[rugabarbo]

В том-то и дело, что мои модули конкретные, а не абстрактные. Продумывать их абстрактными времени нет, потому что переносимость не нужна. Цена абстракции - это доп.время на "продумать".

[zelenin]

В том-то и дело, что мои модули конкретные, а не абстрактные. Продумывать их абстрактными времени нет, потому что переносимость не нужна. Цена абстракции - это доп.время на "продумать".

ок, перефразирую:
Пример: любой чей-то модуль пользователей (не какой-то конкретный).

[Prosto_Tok]

забудь о том, что тебе посоветовали. Делай общий модуль, который является бэкендом же, а фронт вообще к модулю не относится. Теперь поясню: модуль должен реюзабельным, переносимым в другой проект. Бэкенд будет везде одинаковый, а фронт проектозависим, поэтому в модуль его включать глупо.
И ни в коем случае не плодить дочерние модули.

Вот теперь запутался еще больше)
Хотя я больше придерживаюсь позиции zelenin насчет размещения логики работы в одном месте, но тогда по факту получается тот же basic.
И тогда возникает проблема с "балансом",т.е. у фронтеда всего 1 экшн для вывода информации, а у бэкэнд 4(Index,add,edit,delete). Это лишь пример, но можно уловить суть,также интересует разделение шаблона на фронтенд и бэкэнд для одного и того же экшена. Если мне распишут небольшой пример с такой организацией, то с радостью выберу "все в 1 месте", пока что вижу только такое "основное в 1 месте, а незначительное по разным приложениям"

[lynicidn]

модуль это не готовый фронтенд и бекенд, это скорее конструктор, набор экшенов работающих с его логикой, моделей работающих с его хранилищем и сервисов (последним желательны интерфейсы), но в модульности с юзаньем ар, вы скоро столкнетесь, что ваш доменный слой изолирован от внешнего мира, внести в него правки - целая проблема, поэтому в модуле хранят базовые связи внутри модели, и дают расширить свою реализацию для common\models с добавленными связями на другие [modules/]models. Бекенд реализация делается в модуле, но как правило она больше демо возможностей + виджетов + какието базовые переводы, юзать backend из vendor'a та еще веселуха, некоторые извращаются расширя контроллер вендора, добавляя тем, "глушат" ненужные экшены - все тлен, по опыту могу сказать, что контроллеры везде как правило свои backend\components\Controller. Должно хватать просто экшенов специфичных, даже виджеты малореюзабельны изза разновидности цсс фреймворков, стилей и даже либ жс
апд: + миграции само собой + консольные комманды, консоль -единственное что можно делать с контроллерами =)

[zelenin]

забудь о том, что тебе посоветовали. Делай общий модуль, который является бэкендом же, а фронт вообще к модулю не относится. Теперь поясню: модуль должен реюзабельным, переносимым в другой проект. Бэкенд будет везде одинаковый, а фронт проектозависим, поэтому в модуль его включать глупо.
И ни в коем случае не плодить дочерние модули.

Вот теперь запутался еще больше)
Хотя я больше придерживаюсь позиции zelenin насчет размещения логики работы в одном месте, но тогда по факту получается тот же basic.
И тогда возникает проблема с "балансом",т.е. у фронтеда всего 1 экшн для вывода информации, а у бэкэнд 4(Index,add,edit,delete). Это лишь пример, но можно уловить суть,также интересует разделение шаблона на фронтенд и бэкэнд для одного и того же экшена. Если мне распишут небольшой пример с такой организацией, то с радостью выберу "все в 1 месте", пока что вижу только такое "основное в 1 месте, а незначительное по разным приложениям"

Basic и advanced никак не относятся к модулям. В модуле у вас контроллеры только для бэка, т.к. он одинаковый в разных проектах. Фронт же каждый раз разный и поэтому в модуль не включается, а реализуется в рамках фронта в каждом проекте.

[andrei.obuhovski]

Можно размазать логику, но зачем? Можно собрать всю логику в одном месте - удобнее. А главное делает модуль автоматом переносимым (но еще не совсем реюзабельным, поскольку в условиях yii это можно сделать только на простом уровне http://www.yiiframework.ru/forum/viewto ... 19&t=23349 )

1) Чем пострадает переносимость, если вместо 2 папок будет 3? Или речь о модуле как расширении?
2) Причем тут логика, если вопрос о контроллерах?
3) Чем плохо включать фронтенд в модуль(расширение)? Хорошо ведь когда демка есть, особенно если модуль большой (модуль форума, например). Причем, переопределяется же не сложно.

[zelenin]

1) Чем пострадает переносимость, если вместо 2 папок будет 3? Или речь о модуле как расширении?

если вместо 1 папки будет 3. Если вместо одного "вырезать/вставить" делаешь три, то это уже непереносимо.

2) Причем тут логика, если вопрос о контроллерах?

вопрос об организации кода

3) Чем плохо включать фронтенд в модуль(расширение)?.

оно там не нужно.

Хорошо ведь когда демка есть, особенно если модуль большой (модуль форума, например).

согласен. В папку example запихните, опишите в документации подробно. Зачем в сам модуль пихать то, что не будет юзаться?

[andrei.obuhovski]

В папку example запихните, опишите в документации подробно.

Как эту папку подключить в приложение без модуля?

Зачем в сам модуль пихать то, что не будет юзаться?

Вполне может юзаться. Пример, этот форум.