ой, это еще в 2.5-2.6 версиях где-то они туда-сюда меняли это поведение

Ну не без причины же наверно? Теперь весь проект лопатить приходится.

Ну не без причины же наверно? Теперь весь проект лопатить приходится.

ну вообще эту опцию добавили для совместимости

чтобы поменять местами значения и лейблы

а в 3й версии задепрекейтили ее

и в 4й убирают вообще

почему именно так даж не скажу, за этим не следил) но если интересно можно покопать ишьюсы https://github.com/symfony/symfony/search?p=6&q=choices_as_values&type=Issues&utf8=%E2%9C%93

Я к тому что сделали что текст в ключах а значение в value.

https://github.com/symfony/symfony/issues/15606 чет с этим связанное было

нужно ли тестировать ивент сабскрайберы?

нужно ли тестировать ивент сабскрайберы?

да

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

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

уменьшать количество зависимостей. правильно делать декомпозицию, избавляться от primitive obsession и от message obsession

больше юзать value object-ы и т.д.

и моков станет сильно меньше

и моков станет сильно меньше

спасибо

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

и по ним легко трекать изолированно что ты делаешь какую-то дич

http://blog.thecodewhisperer.com/permalink/beyond-mock-objects

вот еще на тему мок объектов

и как не попасть в ловушку с ними

и как не попасть в ловушку с ними

гранд мерси, буду изучать. Тут вот еще вроде инфы в достатке https://refactoring.guru/smells/primitive-obsession

нужно ли тестировать ивент сабскрайберы?

мое мнение - смотря что они делают. Если они просто делигируют логику другим штукам - то нет.

такие вещи покрывают позитивные приемочные тесты

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

тогда такой вот сценарий за неимением условий и логики будет удобно покрываться одним единственным позитивным тест кейсом (end-to-end, приемочные)

[Symfony\Component\Serializer\Exception\UnexpectedValueException] The type of the "localId" attribute for class "BookerBundle\Entity\IntegrationReference" must be one of "string" ("integer" given).

Нужен костыль

Приходит Int, нужно чтобы чтобы приходил strin

g

Расширить энтити? :D

костыль? Геттер левый, или нормалайзер ))

А вообще что-то я в сериалайзере не встречал подобного рода траблы

если только ты там что-то свое придумал хитрое

Использование трейтов в сервисах, для инджекта, скажем, энтити менеджера - это хорошо или плохо?

Просто сам энтити менеджер в сервисе не говорим.

И так понятно что плохо

Я исменно про трейт спрашиваю.

@fes0r Что ты думаешь по этому поводу?

Использование трейтов в сервисах, для инджекта, скажем, энтити менеджера - это хорошо или плохо?

плохо инджектить энтити менеджер в сервисы

их можно только в репозиториях юзать

Я исменно про трейт спрашиваю.

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

а что если в сервисе нужен доступ к базе?

а что если в сервисе нужен доступ к базе?

инджекти репозиторий

не стоит размазывать доктрину по всему проекту

например, сервис, который распихивает данные по объектам и записывает их по тыще репозиториев

например, сервис, который распихивает данные по объектам и записывает их по тыще репозиториев

попахивает херовой декомпозицией

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

на самом деле мне просто не нравится инжектить репозитории

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

А если единой транзакцией должны изменения пройти, связанные с двумя репами?

на самом деле мне просто не нравится инжектить репозитории

когда ты обоснуешь это тогда продолжим разговор)

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

А если единой транзакцией должны изменения пройти, связанные с двумя репами?

flush то у тебя один будет, какая разница. Или ты флашиш в репозиториях?

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

Ну типа конструктор не перегружать. :)

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

можно вернуть какой-нибудь DTO/Vo

Ну типа конструктор не перегружать. :)

что значит "перегружать"?) проблема с наследованием?)

может стоит от наследования отказаться?)

когда ты обоснуешь это тогда продолжим разговор)

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

а еще доменные ивенты начать эксплуатировать

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

пример репозиториев которые я юзаю: class ProductRepository implements Catalog { public function __construct(EntityManagerInterface $em) { $this->em = $em; $this->repo = $em->getRepository(Product::class); } }

flush то у тебя один будет, какая разница. Или ты флашиш в репозиториях?

Один. Я к тому, что em будет в сервис вытянут всё равно.

и все подтягивается автовайрингом, и интерфейсы чистые и вообще ништяк

Один. Я к тому, что em будет в сервис вытянут всё равно.

flush не в сервисах, он обычно в контроллерах или ближе к точке входа.

короч там где ты знаешь что "вот у меня закончилась бизнес транзакция и других перед этим точно не начиналось"

не стоит размазывать доктрину по всему проекту

У меня просто глаз за это замечание зацепился.

У меня просто глаз за это замечание зацепился.

инверсия зависимостей

у меня доктрина изолирована за удобными интерфейсами МОИХ репозиториев.

единственное место помимо репозиториев которые знают о доктрине - контроллеры, потому что это всеравно инфраструктура

ну и где-то ж флашить надо

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

надо просто понимать какие зависимости и как надо изолировать и все)

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

у меня контроллеры взаимодействуют только с http, вся логика в сервисах, которые я иногда вызываю из команд

@fes0r а как ты относишься к такому подоходу - передавать @service_container в конструктор сервиса

Не понятно же от такого подхода какие реально зависимости класс имеет.

Есть сервис, в котором нужны другие 5

Их и надо инжектить

+ стандартных пара

Получится анти-паттерн сервис-локатор если передавать контейнер)

пугает такой конструктор

Понял, спасибо. А по поводу em, может я пропустил, но что делать если нужна транзакция в сервисе

пугает такой конструктор

Возможно сервис занимается слишком многим, чем ему стоило бы.

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

что значит "перегружать"?) проблема с наследованием?)

Да нет. :)). Просто кто-то такой трейт уже создал. И типа использовать его.

@mindtrick скажешь что-нибудь? )

Есть вариант передавать connection для использования миграции (это избавит от em), но хз насколько так правильно

Так если работа с сущностями осуществляется есть смысл именно em и инжектить для флаша.

em что-то уже не хочется использовать, как и сервис контейнер

а альтернатив пока нет)

хотя, можно EntityManagerInterface юзать

Doctrine\DBAL\Driver\Connection

тогда желания getRepository сделать не будет

а. пардон. в родительском интерфейсе есть

ага (

Doctrine\DBAL\Driver\Connection не пойдет?

EntityManagerInterface отличный пример нарушения ISP

@fes0r а как ты относишься к такому подоходу - передавать @service_container в конструктор сервиса

не уважаю

EntityManagerInterface отличный пример нарушения ISP

именно так)