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

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

Да в куче книг пишут про "не лезь в глобалы".

Я бы вообще их ридонли сделал.

Коллеги привет, поделитесь пожалуйста проверенным набором плагинов для симфы под VSCode

Всем привет! Как вы считаете, компоненты (модули) должны вызывать сервисы из других компонентов? У нас в проекте такая структура, что в src лежат директории с компонентами, например, user, profile, department и тд. В каждом компоненте свои контроллеры/подписчики/репозитории/сервисы. Дальше сервисы из одного компонента могут быть использованы в других, но другие сущности (например, репозитории) должны использоваться только в своем компоненте. У меня вопрос: следуя рекомендации по сильному зацеплению/слабой связанности, не должны ли компоненты общаться между собой только через события? Например, создали нового пользователя, отправили событие UserCreated и в других компонентах подписались на это событие и что-то сделали?

Должны да

Тут вроде об этом поднималась тема https://elisdn.ru/blog/149/code-structure

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

Это если нужно прямое взаимодействие

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

Коллеги привет, поделитесь пожалуйста проверенным набором плагинов для симфы под VSCode

intelephense

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

Но это вроде как приводит к раздутому интферфейсу и нарушает solid

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

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

Более того, авторы этих паттернов не рекомендуют притягивать код под паттерн )

Всем привет подскажите. Добавил в таблицу в БД новый столбец, без миграции. Прописал в Entity, но findBy возвращает null в этом поле... Симфони не знаю, но нужно правку внести...

кеш чистили?

Всем привет подскажите. Добавил в таблицу в БД новый столбец, без миграции. Прописал в Entity, но findBy возвращает null в этом поле... Симфони не знаю, но нужно правку внести...

Мб просто старые строки находите, а там при создание столбца null прописался

самое простое прикинул 😁😁😁 не судите если не помог)

Всем привет подскажите. Добавил в таблицу в БД новый столбец, без миграции. Прописал в Entity, но findBy возвращает null в этом поле... Симфони не знаю, но нужно правку внести...

Без миграции не надо

Привет, народ. Нужна помощь коллективного разума :) Ищу библиотеку для clickhouse под doctrine 3. Может кто натыкался на незаброшенный и развивающийся проект? Из того, что нагуглено - нет нормального ORM и миграций, и версия доктрины заморожена на 2. А с нуля писать не очень-то охото.

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

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

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

Ну, щас то так и делаем в основном. Но очень хочется единообразия по сущностям и миграциям для постгреса и кликхауса. А приходится разделять. И иногда властвовать. 😂 А иногда - нет 😅

если вы храните сущности в кх - вы, похоже, что-то делаете не так

из кх, типа, надо селектить грубо говоря что-то вроде select avg(summ) from order

Звучит странно. Какие в КХ сущности и зачем над КХ ORM?

++

Наверное очень много бизнес логики (нет)

Всем привет! Подскажите, а в чем минусы использования трейтов? Понимаю, что иногда они очень уместны, иногда нет, но очень часто слышу, что трейты - это говно) А почему?

Ну, там по разному. Есть статистика - там реально, проще описать сущность, заполнить ее из реквеста и пачкой записать к КХ. И есть агрегаты, для удобства работы агрегированные данные из КХ запихать в сущности от отдать в респонс. Единообразие, я ж говорю. Бизнес-логика ни причём.

Всем привет! Подскажите, а в чем минусы использования трейтов? Понимаю, что иногда они очень уместны, иногда нет, но очень часто слышу, что трейты - это говно) А почему?

Пара минусов которые я вижу: сложновато с разрешением коллизий и лишняя структура в дереве при интерпретации. Но: помогают в DRY, эмитируют множественное наследование (которого нет в PHP, но есть в Java :)). Так что тут просто вопрос уместности.

> эмитируют? в программировании появился термин "эмиссия"?

Всем привет! Подскажите, а в чем минусы использования трейтов? Понимаю, что иногда они очень уместны, иногда нет, но очень часто слышу, что трейты - это говно) А почему?

Когда-то про трейты ответил подробно в комментарии

Всем привет! Подскажите, а в чем минусы использования трейтов? Понимаю, что иногда они очень уместны, иногда нет, но очень часто слышу, что трейты - это говно) А почему?

И отвечал в другом чате: https://t.me/prophp7/252141

> эмитируют? в программировании появился термин "эмиссия"?

имитируют... эмулируют... Это меня, кстати, словарь телеги поправил. Я не виноват 😂

Всем привет! Подскажите, а в чем минусы использования трейтов? Понимаю, что иногда они очень уместны, иногда нет, но очень часто слышу, что трейты - это говно) А почему?

С трейтами все сложно. Я предпочитаю их рассматривать как некая метка, которая функционал привносит. Пример - timestampable, blamable. Такие штуки. Должна быть логическая причина. Но трейты очень любят как попало втыкать, что потом концов не сыщешь. Самый хороший пример - когда один трейт вызывает методы другого трейта. Или методы класса, в который он добавлен. Вот тут уже надо думать над нормальным наследованием, а не трейтами вмазываться.

Или наследование отправить туда же вместе с трейтами

А с наследованием-то что не так? Понятно, что композиция предпочтительнее. Но иногда-то почему нет?

легко переопределить поведение

А с наследованием-то что не так? Понятно, что композиция предпочтительнее. Но иногда-то почему нет?

в каких случаях?

На самом деле, пожалуй, во всех 😁

На самом деле, пожалуй, во всех 😁

я про наследование в каких "иногда"?

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

Наследование плохо масштабируется как по мне

Быстро становится запутанным

Быстро становится запутанным

Особенно в сущностях

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

в итоге парент становиться god object

Привет, народ. Нужна помощь коллективного разума :) Ищу библиотеку для clickhouse под doctrine 3. Может кто натыкался на незаброшенный и развивающийся проект? Из того, что нагуглено - нет нормального ORM и миграций, и версия доктрины заморожена на 2. А с нуля писать не очень-то охото.

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

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

правильно говоришь, но лучше это инфраструктурно решать, а не в приложении. типа ставить clickhouse-bulk, например

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

Обычно рестарт таких приложений крайне редкое явление. Для немедленного сохранения можно и отдельные ендпоинты сделать.

не, моё дело предложить, зачем мне с тобой спорить

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

та я не спорю, понимаю что есть данные, которые нельзя потерять, но это редкий кейс

по крайней мере для использования кликхауса

как миниум, батчить логи в памяти, не особо 12-факторно

кх не только для логов же

да и логи обычно дублируются в файлы

Приветствую. Поделитесь плиз мыслями по проблеме: Есть некий FileSytemInterface , который является Антикарапшеном и File(DTO). Пути - относительные. Есть две реализации LocalSystem, и S3System. При этом LocalSystem можно сконфигурировать на приватную и публичную диру. Система работает со всеми 3 видами. Поидее можно взять File полученный в PublicLocalSystem передать его в PublicLocalSystem->copy(FileSource,FileDist), но естественно не получится сделать PrivateLocalSystem->copy(FileFromPublicSource, PrivateFileDist). Путаница - интерфейс то один. Вопросы основные: 1) Как конфигурировать сервисы использующие стораджи (через интерфейс а в di подставлять конкретный сервис? Или сразу конкретный инстанс). Делал еще через bind: $storage. Но чет все как то все путается. 2) Как работать с кейсом на копирование, перемещение между стораджами? Из PrivateLocalStorage в PublicLoclaStorage. Как я вижу - делать локальную временную копию и через getContent putContent. Но какое то расточительство по ресурсам, если например файл большой будет по сравнению с копированием из одного абсолютного пути в другой. Но с другой стороны - будь один из стораджей S3 - то абсолютный путь пролетает естественно. Была идея еще сделать метод getAbsolutePath который выкидывал бы исключение в s3 адаптере. Но чет тоже "такое себе"

Всем привет! Подскажите, как можно подключить все контроллеры в файл с роутингом? В src создаю директории с модулями, каждый модуль содержит директории, в том числе директорию Controller. В routes.yaml хочу одной инструкцией их подключить, например вот так: controllers: resource: '../src/*/Controller' type: annotation Но ничего не получается)

Всем привет! Подскажите, как можно подключить все контроллеры в файл с роутингом? В src создаю директории с модулями, каждый модуль содержит директории, в том числе директорию Controller. В routes.yaml хочу одной инструкцией их подключить, например вот так: controllers: resource: '../src/*/Controller' type: annotation Но ничего не получается)

Добавь звезду в конец

Controller/*

Всем привет! Подскажите, как можно подключить все контроллеры в файл с роутингом? В src создаю директории с модулями, каждый модуль содержит директории, в том числе директорию Controller. В routes.yaml хочу одной инструкцией их подключить, например вот так: controllers: resource: '../src/*/Controller' type: annotation Но ничего не получается)

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

Controller/*

Даже интересно сработает или нет, так как вложенность при стандартном кейсе работает и без звезды :)

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

Иногда выносят отдельно, иногда можно и внутрь положить, зависит от ситуации

Иногда выносят отдельно, иногда можно и внутрь положить, зависит от ситуации

Ну смысла выходит мало в этом разделении. Сегодня экшен трогает один модуль - располагаем в модуле, на фронте сделали форму на 2 модуля - выносим, потом передумали, обратно тащим в модуль, не удобно

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

спорная, но мы так делаем. Штуки которые меняются вместе находятся вместе

Ну смысла выходит мало в этом разделении. Сегодня экшен трогает один модуль - располагаем в модуле, на фронте сделали форму на 2 модуля - выносим, потом передумали, обратно тащим в модуль, не удобно

возможно модули выделили криво

Ну смысла выходит мало в этом разделении. Сегодня экшен трогает один модуль - располагаем в модуле, на фронте сделали форму на 2 модуля - выносим, потом передумали, обратно тащим в модуль, не удобно

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

Даже интересно сработает или нет, так как вложенность при стандартном кейсе работает и без звезды :)

Сработало, только звёздочку нужно было не в конец добавить, а ещё одну после src/

а мы просто ставим атрибут AsController

и теперь контроллер может находиться в любом неймспейсе

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

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

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

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

Через события я представляю частично, как можно работать. Подскажите, что такое публичный интерфейс? Слышал про это, не понимаю что это значит) А по поводу событий - как они помогут, если нужно отдать данные? Вот на примере: нужно мне вместе с товаром теги отдавать, я вызову ProductController, который вызовет ProductService, который в свою очередь вызовет ProductRepository или ProductQuery, которые в свою очередь сходят в две таблицы и отдадут данные. А у вас бы как это выглядело?

Через события я представляю частично, как можно работать. Подскажите, что такое публичный интерфейс? Слышал про это, не понимаю что это значит) А по поводу событий - как они помогут, если нужно отдать данные? Вот на примере: нужно мне вместе с товаром теги отдавать, я вызову ProductController, который вызовет ProductService, который в свою очередь вызовет ProductRepository или ProductQuery, которые в свою очередь сходят в две таблицы и отдадут данные. А у вас бы как это выглядело?

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

У нас в проекте порядка 50 модулей. В трети из них контроллеры возвращают данные из нескольких сущностей. Это какая каша получится?)

Что такое публичный интерфейс?) Это как выглядит?

https://milestone.topics.it/series/view-model-composition.html