Как правильно использовать вложенные бандлы?

Question

[grabbee]

Хочу в (APP)приложении установить один (А)бандл, который внутри расширяет(дополняет) (Б)другой. Они очень похожи, просто дополняют друг друга. Самостоятельно может работать только (Б)бандл. (А)бандл жестко зависит от (Б)бандла и является его более функциональной версией.

Правильно ли я понимаю, что мне нужно фактически продублировать конфигурацию (Б)другого бандла в (А)бандл. Потом в (А)Extension через (А)CompilerPassInterface подменить параметры этого (Б)бандла на новые, которые пришли из конфигурации (А)бандла

Затем в самом (APP)приложении мне нужно будет установить и настроить только один (А)бандл и не использовать (APP)Extension вообще

Я всё правильно делаю? :)

Answer 1

[Максим]

Вопрос в заголовке про использование, а внутри про объединение…)

Без кода сказать сложно что куда лучше перенести. Расширять один бандл тоже можно по-разному, где-то просто скопировать класс из одного и перенести в другой, затем подменить в DI контейнере, где-то влезть через события, а где-то решить вопрос наследованием.

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

Кроме того, я бы попробовал сделать pull request с вашими дополнениями, возможно их включат в основной бандл.

Переносить из Б в А не вижу смысла, так как кода явно будет больше, раз Б работает самостоятельно, а А от него зависит.

Также не вижу ничего плохого в том, что один бандл будет зависеть от другого. Вполне бандл А может жить и без объединения с бандлом Б. Главное следите за обновлением зависимостей.

Comments

[grabbee]

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

В данном случае один (Б)бандл формирует токены JWT+refresh токен. А второй (А)бандл расширяет его остальным функционалом - регистрация, контроллер входа, напоминание пароля и так далее.

Хочу чтобы при установке "полного" (А)бандла через один общий конфиг всё настроить. Чтобы не тянуть дополнительно (Б)бандл и не настраивать его отдельно.

Я уже всё сделал. Просто интересно, по феншую или нет...

[Максим]

grabbee, Вы слишком не правильно понимается принцип DRY. В вашем случае лучше эти все вещи скопировать в каждый свой проект, либо этот бандл сделать полноценным сервисом/микросервисом - Auth. Вполне себе хороший сервис. С такими темпами вы придумаете бандл для приложения, чтобы бандл сразу в трех приложениях делал всё общее для трех приложений. Путь в никуда с жесткими зависимостями)

Если уж совсем не хочется так, то можно жить с этим как объединив, так и не объединив. Настройки для бандла Б можно включить в бандл А и всё будет работать)

[grabbee]

лучше эти все вещи скопировать в каждый свой проект

Я уже пробовал. Обновлять это потом как? Я переписываю и обновляю "общие вещи" регулярно. Лезть потом в каждый и править там?.. Это ночной кошмар, как по мне))

С такими темпами вы придумаете бандл для приложения

Я уже в этом месте :)

Например на основе бандла авторизации легко сделать сервис, просто установив туда его. Или впихнуть этот бандл в монолит, и работать будет одинаково с теми же настройками(настройки по умолчанию тоже)

Но я пока не ощутил что лучше. Проблемы с зависимостями или проблемы с дублированием кода. Решение конфликтов зависимостей багов не привносит. А отдельные версии кода - я через два дня забываю где что писал))

[Максим]

grabbee,

Я уже пробовал. Обновлять это потом как? Я переписываю и обновляю "общие вещи" регулярно. Лезть потом в каждый и править там?.. Это ночной кошмар, как по мне))

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

Я уже в этом месте :)

Поздравляю. Вы «на правильном» пути)

Но я пока не ощутил что лучше. Проблемы с зависимостями или проблемы с дублированием кода. Решение конфликтов зависимостей багов не привносит. А отдельные версии кода - я через два дня забываю где что писал))

Значит ваш бандл простой, мало изменяется и такие же приложения. В серьёзном проекты вы бы получили массу проблем и багов. Это может пойти по разным путям. Где-то будут миграции мешать, где-то php72, а где-то уже php81 и т д. Если не встречались с проблемами - не значит что они не будут) Как я уже говорил - идеально вынести в отдельный сервис и взаимодействовать по api. Но тут уж сами решайте. Здесь точно такая же проблема, как с универсальной моделью, в которой у вас есть User с 50-100 полями в базе. Да, вы ничего не копируете, всё есть в User (и даже чего не надо), но такая запутанность даёт много проблем. Например, null поля. В разных контекстах этот же User может быть Автором, Покупателем, кладовщиком, поваром и т д. И все 50 полей распределятся по контекстам.

[Максим]

Многократное использование кода и дублирование кода — разные вещи. DRY гласит, что не нужно дублировать знания, а не что нужно всегда делать код многократно используемым.

Про DRY можно почитать тут https://habr.com/ru/company/vk/blog/349978/

[grabbee]

Максим, благодарю. Всё так и есть. Писаю против ветра в свободное от работы время...
Пока по озвученным проблемам нашел решения

где-то php72, а где-то уже php81

"php": ">=7.4.0",
Не даст установить бандл. Нужно будет сначала его обновить до используемой версии. То есть в новом приложении с php 8 запустится новый бандл. А в старых нет, нужно будет довыпустить версию для старых проектов, либо обновить сами проекты.

с универсальной моделью, в которой у вас есть User с 50-100 полями в базе

@ORM\MappedSuperclass
Не нужно. Сейчас делаю базовый СуперКласс, Интерфейс. От них, если нужно что-то ещё, наследуюсь. Только начинаю свой "правильный" путь. Может оно и не правильно.

будут миграции мешать

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

и точно так же сидеть ночами

Мне так спокойнее, никто не отвлекает. Я очень нервный. Орущие дети или собаки за окном сильно дискоординируют :)

[Максим]

Не даст установить бандл. Нужно будет сначала его обновить до используемой версии. То есть в новом приложении с php 8 запустится новый бандл. А в старых нет, нужно будет довыпустить версию для старых проектов, либо обновить сами проекты.

Ну вот) А теперь представьте. Бандл сделали с поддержкой 81, одно приложение перевели с 72 на 81. Два остались на 72 времени нет. И уже конфликт) А новыми фичами уже пользоваться хочется))

Не нужно. Сейчас делаю базовый СуперКласс, Интерфейс. От них, если нужно что-то ещё, наследуюсь. Только начинаю свой "правильный" путь. Может оно и не правильно.

Вот это тоже плохо)) Ну учитесь)

В общем я лишь сказал вам часть причин, но это вам не проблема. Поэтому оставляйте так, а со временем сделаете выводы)