Dmitriy
выделяете интерфейс, в цикле в контроллере запускаете резолверы из разных модулей
Dmitriy
резолверы реализуют интерфейс в своих модулях
Dmitriy
как результат у вас слабая связь между модулями
Dmitriy
это к вопросу получения данных из разных модулей
Dmitriy
symfony tagged iterator
Павел
возможно модули выделили криво
Возможно да, а возможно и нет. Модуль профайл, модуль нотификации и управление оповещениями. А форма и запрос - один. Банальный bff в качестве которого и выступает контроллер
Павел
Или например рефакторинг и разделение, соединение модулей. Почему это должно влиять на http интерфейс не понятно
Kirill
выделяете интерфейс, в цикле в контроллере запускаете резолверы из разных модулей
Нет ли примера такой реализации? На слух не очень понятно, как это работает
Dmitriy
https://symfony.com/doc/current/service_container/tags.html#reference-tagged-services
Павел
В идеале модули или не общаются, или по ивентам (где нет сущностей), или через антикарапшен лайер
Павел
В разных модулях могут быть свои user, order сущности например. С разными свойствами нужные только в этом модуле. Но имеют один id, через который и соединяются
Павел
На практике все равно часто каша выходит, но надо стараться)
Павел
выделяете интерфейс, в цикле в контроллере запускаете резолверы из разных модулей
А в этом какой смысл? Контроллер верхний слой, он может знать о модулях
Павел
А вот внутри модуля, уже наверное можно что то такое намутить. Если без антикарапшена, а через di
Dmitriy
Нет единого верного пути
Dmitriy
у вас так, у нас так
Dmitriy
мы пробовали в одном проекте хттп слой "над модулями", нам не зашло, может что-то делали не так
Юра
https://habr.com/ru/post/427739/
Юра
Вот еще
Юра
Есть статья с примерами гексагональной или луковой архитектуры на ларавель
Юра
Как по мне все это имеет смысл если приложение довольно большое и сложное
Юра
Если это просто круд над базой, то никакого смысла нет
Kirill
Подскажите, пожалуйста, как ко всем роутам добавить префикс?
Вот так пробую, не добавляется
controllers:
resource: '../src/**/Controller/*'
type: annotation
prefix: /api
Kirill
а теперь добавляется)
Юра
Кеш наверное
Vlad
в любой не понятной ситуации делай rm -rf var
Юра
var/cache только
Konstantin
главное не /var
Vlad
у меня был такой кейс) сказал коллеге снеси var
Vlad
он пошел и снес /var
Vlad
хорошо что это был контейнер
Vlad
и шторма есть история
Kirill
А подскажите, пожалуйста, как маппинг для доктрины написать так, чтобы он подключал все Entity внутри модулей?
doctrine:
orm:
mappings:
App\Component\Benefit:
is_bundle: false
type: annotation
dir: '%kernel.project_dir%/src/Component/Benefit/Entity'
prefix: 'App\Component\Benefit\Entity'
alias: App\Component\Benefit
Если пытаюсь указать /src/**/Entity, то получаю ошибку
Specified non-existing directory "/var/www/backend/src/**/Entity" as Doctrine mapping source
Юра
Я думаю ты занимаешься не тем
Юра
Тебе надо конфигурации в пхп делать
Юра
Мне так кажется
Юра
В доктрине глоб не будет работать скорее всего
Kirill
эх
Юра
И вообще лучше делать каждый модуль бандлом наверное
Юра
По крайней мере у симфы бандл это минимальный кусок общего кода
Юра
И подключать энтити из этих бандлов
Юра
Каждый бандл может добавлять в доктрин конфиг свой мапинг
Юра
Плюс можно вообще вынести бандлы потом в свой приватный репозиторий и подключать на разных проектах
Юра
И автоматически зависимости композером будут хендлится
Юра
Так что сильно рекомендую сразу этот подход
Dmitriy
бандлы как раз дока не рекомендует для БЛ
Dmitriy
А подскажите, пожалуйста, как маппинг для доктрины написать так, чтобы он подключал все Entity внутри модулей?
doctrine:
orm:
mappings:
App\Component\Benefit:
is_bundle: false
type: annotation
dir: '%kernel.project_dir%/src/Component/Benefit/Entity'
prefix: 'App\Component\Benefit\Entity'
alias: App\Component\Benefit
Если пытаюсь указать /src/**/Entity, то получаю ошибку
Specified non-existing directory "/var/www/backend/src/**/Entity" as Doctrine mapping source
mappings:
App:
is_bundle: false
type: attribute
dir: '%kernel.project_dir%/src/'
prefix: 'App\'
alias: App
Gleb
Ребята, а расскажите ваше мнение по вопросу:
есть сервис, условно на 15 методов. Примерно 50/50 они используют репозиторий.
Вы бы репозиторий вытащили в autowiring или инициализировали только в нужных методах?
с одной стороны оверхед получается на autowiring, с другой дублирование кода.
Konstantin
да нет там оверхеда
Konstantin
а тестировать проще когда зависимости явно передаются
Gleb
Спасибо, понял. Плюшки перевешивают спички.
Павел
Ребята, а расскажите ваше мнение по вопросу:
есть сервис, условно на 15 методов. Примерно 50/50 они используют репозиторий.
Вы бы репозиторий вытащили в autowiring или инициализировали только в нужных методах?
с одной стороны оверхед получается на autowiring, с другой дублирование кода.
Я бы еще посмотрел, что за сервис такой, что использует 15 методов, возможно стоит разделить
Konstantin
да мошт рассылки какие, там обычно всегда вперемешку все
Gleb
Я бы еще посмотрел, что за сервис такой, что использует 15 методов, возможно стоит разделить
Возможно. Это прослойка между репозиторием и контроллером.
Контроллеры пока не в action oriented подходе сделаны, там тоже куча получается и скорее всего это всё можно распилить. Но я пока просто пилю учебный проект с некоторыми допущениями на "говнокод".
Павел
Возможно. Это прослойка между репозиторием и контроллером.
Контроллеры пока не в action oriented подходе сделаны, там тоже куча получается и скорее всего это всё можно распилить. Но я пока просто пилю учебный проект с некоторыми допущениями на "говнокод".
Это скорее всего аппликейшен сервисы у вас. Можно разделить на 1 метод - 1 класс. Контроллеры часто тонкие и можно много методов.
Основной минус - что ваш сервис в перспективе будет миллион строк кода и миллионн зависимостей с проблемами, которую вы описали только про репо
Павел
И при желании тестирования, такие сервисы тестировать боль. Добавляете 16 метод с новой зависомостью, и если собирали данный сервис не через di , то упадут 15 тестов на другие методы, так как конструктор невалидный
Gleb
Это скорее всего аппликейшен сервисы у вас. Можно разделить на 1 метод - 1 класс. Контроллеры часто тонкие и можно много методов.
Основной минус - что ваш сервис в перспективе будет миллион строк кода и миллионн зависимостей с проблемами, которую вы описали только про репо
Уточню, это сервис на круд к сущности.
Соответственно те же вариации выборок накидывают методов.
Павел
какой то большой круд))
Павел
Уточню, это сервис на круд к сущности.
Соответственно те же вариации выборок накидывают методов.
Прослойка чисто для выборок - тоже ничего кошерного не дает, кроме "слоистой архитектуры"
Gleb
И при желании тестирования, такие сервисы тестировать боль. Добавляете 16 метод с новой зависомостью, и если собирали данный сервис не через di , то упадут 15 тестов на другие методы, так как конструктор невалидный
Спасибо, тесты я писал давненько уже (на последней работе был битрикс и не было тестов. 😂😂😂), уже не всё помню. Но логика понятна, т.к точно не везде di был в них.
Gleb
Прослойка чисто для выборок - тоже ничего кошерного не дает, кроме "слоистой архитектуры"
У меня как-то первый опыт с фреймворками получился с симфой и DDD сразу. :) я другого по факту и не видел.
Павел
У меня как-то первый опыт с фреймворками получился с симфой и DDD сразу. :) я другого по факту и не видел.
Ох уж этот DDD ) он у всех и мало у кого ) DDD шредингера)
Konstantin
*паста про ddd - это как подростковый секс*
Gleb
Все говорят что им занимаются, но занимается им мало лишь кто?)
Юра
DDD это когда сначала домен зарегать надо?
Павел
Все говорят что им занимаются, но занимается им мало лишь кто?)
Все занимаются, но по факту мало у кого наверное получается)
Ну к примеру DDD - это про единый язык и контексты. Вы в пет проекте сами с собой единый язык устанавливатее?)
Юра
Домен, потом базу, потом доширак
Павел
Типо в идеале можно написать логику и сущности, сервисы и прочее не имея базы))
Юра
Doshirak Driven Development
Gleb
Все занимаются, но по факту мало у кого наверное получается)
Ну к примеру DDD - это про единый язык и контексты. Вы в пет проекте сами с собой единый язык устанавливатее?)
Согласен.) с языком то проще, а вот контексты поразделять полезно. Я пришёл в разработку из бизнеса так сказать. Мне причины этого подхода очень понятны.
Павел
Согласен.) с языком то проще, а вот контексты поразделять полезно. Я пришёл в разработку из бизнеса так сказать. Мне причины этого подхода очень понятны.
Полезно да, еще полезно разделять их правильно :)
Например сегодня вот человек писал тут что у него куча модулей зависимых презависимых, вроде контексты а вроде и нет. Ну и на малом проекте сложно самому себе палки в колеса вставлять.
Короче на практике реального проекта все сложнее выходит.
Это в статьях и примерах: тут кухня, тут доставка, тут прием заказов. И вроде ниче не пересекается даже на словах)
Gleb
Да я уже на этом учебном проекте палок себе повставлял.)
Пока работаешь с cms, как-то проще это всё. А тут минимальный небольшой сервис спроектировать и по факту нормально не смог.
Kirill
Kirill
Помогите. У меня в src лежат папки с подулями, в каждом модуле Entity. Мне сейчас нужно для всех модулей указывать путь до папки Entity, чтобы доктрина их увидела. Не получается в yaml формате одном инструкцией все подключить. Мне тут посоветовали на php конфиги использовать, но я что-то примеров не могу найти в документации. Как мне конфиги для доктрины описать в php? Куда какой файл класть/что писать/где подключать?)
Павел
Помогите. У меня в src лежат папки с подулями, в каждом модуле Entity. Мне сейчас нужно для всех модулей указывать путь до папки Entity, чтобы доктрина их увидела. Не получается в yaml формате одном инструкцией все подключить. Мне тут посоветовали на php конфиги использовать, но я что-то примеров не могу найти в документации. Как мне конфиги для доктрины описать в php? Куда какой файл класть/что писать/где подключать?)
Тоже послушаю, еще вроде есть варик в каждом модуле настройки держать, но сам не пробовал как это все мержится потом
Павел
Помогите. У меня в src лежат папки с подулями, в каждом модуле Entity. Мне сейчас нужно для всех модулей указывать путь до папки Entity, чтобы доктрина их увидела. Не получается в yaml формате одном инструкцией все подключить. Мне тут посоветовали на php конфиги использовать, но я что-то примеров не могу найти в документации. Как мне конфиги для доктрины описать в php? Куда какой файл класть/что писать/где подключать?)
Дока по php вот https://symfony.com/doc/current/reference/configuration/doctrine.html#custom-mapping-entities-in-a-bundle
Надо самому чтоли тоже посмотреть, а каком нить цикле или glob директории на автомате смотреть)