Как в Symfony сделать предварительную инициализацию модуля (бандла)?

Question

[Григорий Васильков]

Пока ещё не изучил Doctrine, и хотел бы подключить Eloquent ORM к проекту на Симфони.
Не нашел другого способа зарегистрировать что-то в контейнере, как создать бандл и добавить его в config/bundles.php

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

Однако капсюль Eloquent при каждом запросе должен быть сконфигурирован

В других фреймворках я писал какой-то там boot.php и через require или другим способом подключал его где-то.

Есть ли другой способ для Symfony, чтобы не создавать Бандл, для него не создавать Extension, а в config/services.php не регистрировать создание обьекта через какой-нибудь EloquentFactory.class.php?

Как я понимаю только таким образом в симфони делаются так называемые shared-сервисы (проще говоря - синглтоны)

ps. мне также хотелось бы понять каким образом мне использовать env-переменные в моём бандле, который понятия не имеет о env- всего приложения. Вернее физически то имеет, я могу вызвать и получить. Но если этот бандл кому отослать, то переменных окружения у него может не быть и модуль не запустится

спасибо

Answer 1

[index0h]

хотел бы подключить Eloquent ORM к проекту на Симфони.

Это ж одна из худших ORM..., но дело ваше.

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

Не совсем так. Контейнер содерждит сервисы, в идеале - statless, но ничто кроме хорошего тона и архитекутры вам не мешает пихать туда все что угодно.

Таким образом создав его дважды в двух разных модулях получится два одинаковых подключения к базе данных.

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

Однако капсюль Eloquent при каждом запросе должен быть сконфигурирован

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

Есть ли другой способ для Symfony, чтобы не создавать Бандл, для него не создавать Extension

Конечно, берете и не создаете бандл.

а в config/services.php не регистрировать создание обьекта через какой-нибудь EloquentFactory.class.php?

А вот контейнер наконфигурить таки надо. Не обязательно через фабрику.

Как я понимаю только таким образом в симфони делаются так называемые shared-сервисы (проще говоря - синглтоны)

Синглтоны тут ни при чем, это DI.

мне также хотелось бы понять каким образом мне использовать env-переменные в моём бандле

С вероятностью 146% вам это не нужно, когда из коробки появилась поддержка env файлов мы с коллегами попытались их интегрировать, по жили с ними какое-то время. Профитов не обнаружили и вернулись к parameters.yml.dist.

который понятия не имеет о env- всего приложения. Вернее физически то имеет, я могу вызвать и получить.

Вот именно в этом и состоит DI, сервис не знает, ни где ни как его будут использовать, его конфигурированием занимается контейнер.

Но если этот бандл кому отослать, то переменных окружения у него может не быть и модуль не запустится

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

UPD

Как в Symfony сделать предварительную инициализацию модуля (бандла)?

Вам скорее всего нужно зарегистрировать просто сервис: https://symfony.com/doc/current/service_container....

Comments

[Максим Федоров]

Профитов не обнаружили и вернулись к parameters.yml.dist.

Через один проект стоит Incenteev :)

[index0h]

Максим Федоров, это годная штука

[Максим Федоров]

index0h, да, понимаю... но мне ближе env все же :)
хотя во всех проектах, где работал всем было сложно менять парадигму обслуживания и все этот плагин юзали

[index0h]

Максим Федоров, можете объяснить, в чем киллер фича env?

[Григорий Васильков]

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

Короткий ответ на вопрос "по другому невозможно"?

Бандл - его в глобальные бандлы, для бандла - экстеншен, в экстеншене лоад.

Если мы делаем разные модули в рамках монолита как подключать свои собственные сервисы не изменяя файл который правит коллега? И параметр получить $this->config? или они здесь только, кхм, "внедряются"?

[index0h]

@gzhegow

Короткий ответ на вопрос "по другому невозможно"?

Почему же, возможно.

Если ориентироваться на доку, заводиться это должно примерно так (services.yml):

Illuminate\Database\Capsule\Manager:
    calls:
      - [addConnection, ['%mysqlConnection%']]

Здесь mysqlConnection - это параметр в parametrs.yml содержащий массив для addConnection.
Если я правильно понял - контейнер и диспатчер нужно подключать отдельно.

Там, где вам надо - указываете аргумент с классом Illuminate\Database\Capsule\Manager в конструкторе и радуетесь жизни.

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

Конфликты в services.yml и подобных иногда случаются, но это не то что бы прям бида.

И параметр получить $this->config? или они здесь только, кхм, "внедряются"?

Внедряются, конфиг отдельно нужен ну очень в редких ситуациях.

[Григорий Васильков]

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

[index0h]

Григорий Васильков, env вам скорей всего не надо, хайп уже прошел, это очень переоцененная фича

[BoShurik]

Максим Федоров, вот тоже не понимаю зачем они нужны.
Если очень хочется, то можно использовать в parameters.yaml что-то вроде

parameters:
    env(APP_SECRET): some-secret

И эта переменная будет затираться реальными переменными окружения. dotenv компонент не нужен.

При этом мы теряем возможность гибко конфигурировать контейнер. К примеру если у нас есть параметр отвечающий за отправку sms sms_enabled. В простом случае было бы что-то вроде

// \App\Kernel
protected function configureContainer(ContainerBuilder $container, LoaderInterface $loader): void
{
    // ...
    if (!$container->getParameter('sms_enabled')) {
        $container->setAlias(SmsSenderInterface::class, DummySmsSender::class);
    }
}

В случае с env(SMS_ENABLED) такое сделать не получится, т.к. на этапе компиляции значение не известно. Надо будет городить фабрику в которой создавать нужный нам инстанс.

Да, мы теряем возможность на лету менять этот параметр, но на практике такое нужно почти что никогда

[index0h]

BoShurik, более-менее годный use-case для env - это параметризация через переменные окружения в Docker. Для консольных приложений полезность фичи притянута за уши.

[BoShurik]

index0h, но если Docker не используется, то конфигурировать такие приложения в двух местах становится крайне неудобно

[Григорий Васильков]

index0h, ну в целом я стремлюсь хранить настройки, которые делаются для проги в одном пусть даже большом файле

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

нет другой причины делать мало конфигов и класть их в одном месте

[Григорий Васильков]

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

[index0h]

Григорий Васильков Для вагранта есть следующий подход:
1. Вагрантовый синк стоит отключаить вовсе. Он очень медленный, особенно когда симфони начинаете генерить кучу кэша.
2. Настроить диплой в вашей IDE при изменении.
3. Завести parameters.yml и parameters.yml.dist. Первый заигнорен в git, второй коммитится. В dist файле добавьте конфиги по умолчанию именно для вашего dev окружения.

Для автогенерации параметров - есть годная штука https://github.com/Incenteev/ParameterHandler , о ней тут уже упоминали.

[Григорий Васильков]

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

[Григорий Васильков]

index0h, подожди, какой автогенерации, каких параметров?

Я как приложение вижу:
есть конфиг глобальный, под приложение.
у приложения есть бандлы (приложения поменьше), которые могут в свою очередь тоже содержать бандлы и так далее

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

причем тут новые библиотеки по генерации параметров, что всё так сложно вдруг стало с обычными return array(); ?

[BoShurik]

Григорий Васильков, если речь о бандле, то эта функциональность реализуется через Extension (\Symfony\Component\DependencyInjection\Extension\ExtensionInterface::load)

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

С чего вы это взяли? И что значить "предварительная инициализация"?

[Григорий Васильков]

BoShurik, спасибо

Ну вот я хочу элокуент капсюль, это именно тот самый лоад, о котором мы с тобой говорим. Там нужно создать обьект-менеджер, сохранить его (в будущем это сервис "дб"), в него прокинуть конфиги, поставить галочку "использовать глобально" - чтобы AR-модели подцеплялись к этому "соединению-по-умолчанию", проще говоря если мне потребуется обратиться в базу данных, модуль нужно инициализировать или при старте приложения или при первом обращении к билдеру запросов - но они не предполагают реализацию фабрики, которая создает билдеры и при первом билдере - подключается в базе - они рекомендуют при старте приложения настраивать обьект-соединение, которое подключится в базе когда мы сделаем первый селект.

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

Таким образом я пытаюсь понять как реализовывать такие вот модули, которые требуют предварительной настройки, пытаюсь понять отличие от ларавеля - где для этого были сервис-провайдеры, отличия от фалкона - где это просто было в php файлах через $di->setShared($interface, $className), или собственного DI где использовались колбэки для того, чтобы получить из $di зависимости и прокинуть их на свои места.

Документация предлагает создать параметр $config, который прокинуть через
->arg('array $config', $config);
но при этом значения этого конфига я хочу прокидывать из вагранта через env() или _более_простым_ способом, а не организовывать генератор кода, который будет что-то там под капотом себе делать, что я потом людям, кто с трудом понимает зачем AR никак не объясню.

Здесь просто немного отличается подход, и я не могу вкурить как именно, а документации на блогах написано "просто напишите services.yml и всё заработает", ни как прокинуть конфиги с верхних слоев вниз - ничего, ни как сделать полностью отдельный модуль, который не знает про внешнее приложение почти ничего - ни слова, все блоги шустрят настройками виртуальных машин и чем угодно кроме такой банальной вещи как я пытаюсь найти

[BoShurik]

Григорий Васильков, может вам просто взять EloquentBundle

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

Вероятно вам поможет создание конфига для бандла
К примеру вот это
для того чтобы описать вот такой конфиг

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

[Григорий Васильков]

BoShurik, я не слишком рассуждаю за архитектуру, не руби с плеча

Ссылки сейчас буду читать, задам вопросы

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

Пусть каждый пишет свой небольшой кусок программы. Даже если этот кусок - забрать из гета "реферал_айди", положить в куки, и сделать редирект, очистив ссылку от реферал_айди. Пусть это будет маленький бандл который человек закончит и подключит потом где нужно, подкинув сервис выполняющий задачу на вход нужного контроллера.

[Григорий Васильков]

BoShurik, ознакомился со статьями, первую читал и после неё вопрос и задал

Создание любого кусочка программы представляет собой целый список действий что-ли?
1. обязательно создать файл /config/packages/mymodule.php (в глобальной папке??)
2. создать папку App/Bundle/MyModuleBundle
3. создать файл App/Bundle/MyModuleBundle/MyModuleBundle.php -> метод как-то там ~getExtension()
4. создать файл App/Bundle/MyModuleBundle/DependencyInjection/Configuration.php -> метод getConfigTreeBuilder()
5. создать файл App/Bundle/MyModuleBundle/DependencyInjection/Extension.php -> метод load()
6. создать папку App/Bundle/MyModuleBundle/Services/MyModuleService.php -> собственно какие-то действия, которые потом от модуля будут требоваться
7. создать файл App/Bundle/MyModuleBundle/Resource/config/services.php -> зарегистрировать MyModuleService, который будут существовать в единственном экземпляре. И здесь ли забиндить их на интерфейсы? (App/Bundle/MyModuleBundle/Interfaces/MyModuleInterface.php). Как быть с теми вещами, которые биндятся на интерфейс, но при этом могут быть созданы под каждую задачу снова? Или в этом случае их нет смысла биндить на интерфейс?
8. И в каком-то из этих 7 мест каким-то загадочным образом прокинуть конфигурацию сверху к модулю, чтобы программист мог исправляя единый конфиг менять настройки отдельного модуля, а если в едином конфиге пусто - использовать конфиг самого бандла

Короткий вопрос, блин это всегда так чтоли? Мои ребята (и я) башкой упадут просто не забыть, что это всё нужно иначе оно не взлетит.

[index0h]

Григорий Васильков

а как насчет бандла?

Не нужен вам бандл, app - это и есть ваш бандл.

Это в каждом бандле создается кернель и весь контейнер конфигурится оттуда?

Почему же? Все сторонние бандлы, что вы используете в своем приложении отлично конфигурируются централизированно.

подожди, какой автогенерации, каких параметров?

То, что внутри parameters.yml - это настройки конкретного окружения. Например доступы к конкретно вашей тестовой БД, конкретно ваш хттп домен и т.д. На продакшне parameters.yml будет свой.
Автогенерация нужна на этапе диплоя на дев машинах ваших колег. Что бы каждый руками этого не делал.

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

Нет. Вы используете бадл в своем приложении, и там же и конфигурируйте его. Сторонние бандлы по хорошему у вас все равно будут в vendor каталоге.

Там нужно создать обьект-менеджер, сохранить его (в будущем это сервис "дб"), в него прокинуть конфиги

Я ж вам пример привел, как зарегать в вашем апликейшне сервис вашего капсуля. Какие бандлы, какие экстеншны, на кой оно вам надо? Хотите капсуль - юзайте капсуль, лишними обвязками вы только себе жизнь усложните.

Тут же весь конфиг так и пестрит тем что я должен обязательно сервису дать имя в дот-нотации, чего? Я зачем отвыкал, тренд был, а теперь кончился?

Дык юзайте имя класса, в чем проблема?

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

Еще раз, если вы хотите создавать именно модули для публикации, без аппликейшнов - это одно.
Если вы хотите именно у себя в апликейшине это использовать - это совсем другое.
Для апликейшна НЕ НАДО ПЛОДИТЬ БАНДЛЫ, ваш аппликейшн уже таковым является.

Документация предлагает создать параметр $config, который прокинуть через
->arg('array $config', $config);
но при этом значения этого конфига я хочу прокидывать из вагранта через

Документация предлагает вам оформить настройки, которые требуются для собственного независимого бандла. Вы, как создатель бандла не знаете, да и не контролируете, откуда будут браться эти настройки, из yml, xml, env да хоть php.

или собственного DI где использовались колбэки для того, чтобы получить из $di зависимости и прокинуть их на свои места.

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

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

Настройки указываются в services.yml для конкретного сервиса, там где они будут использоваться. Зачем их прокидывать в верх, или вниз? Если вам надо одни и те же настройки для двух сервисов - в чем проблема, опишите для двух.

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

Если так, вам точно это нужно в одном проекте?))

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

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

[index0h]

Григорий Васильков,

Короткий вопрос, блин это всегда так чтоли? Мои ребята (и я) башкой упадут просто не забыть, что это всё нужно иначе оно не взлетит.

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

[index0h]

@gzhegow
Если вы так хотите прям разделить работу пусть первый пишет в каталоге src/Services/FirstVeryPerfectService, а второй в src/Services/SecondVeryPerfectService. По БД с вашим Eloquent все равно система будет связана по самое не балуйся, роутинг можно разделить на несколько отдельных yml файликов для первого и для второго.
Контроллеры тоже по каталогам делятся

[Григорий Васильков]

спасибо ещё раз
Eloquent планируется использовать внутри БДРепозитория, а не везде в проекте. Вокруг него будет квери билдер с возможностью отфильтровать даже массив обьектов.