array_map($query->getArrayResult(), function($row) { return new SomeComplexObject(new SomeOtherObject(u.id, u.profile.name));});

аргументы только наоборот)

да, можно так конечно

но тогда ты теряешь эмбеддед объекты (VO)

ну то есть.... либо ты остаешься совсем без мэппингов и делаешь свой

ну и хуй с ними

ну и хуй с ними

да ладно, я ленивый

хочу все в dql описать)

new UserProfileView(u.id, u.profile, u.somethingElse)

А с этим разве сейчас есть проблемы?

А вот второй вариант со вложенными DTO - интересно выглядит.

Можно, конечно, на уровне конструктора разруливать, в принципе.

Можно, конечно, на уровне конструктора разруливать, в принципе.

сложно реюзать код)

Всем привет! Начинаю тут понемногу переписывать старый прототип на что-то нормальное, выбрал, соответственно, симфони. И столкнулся с такой проблемой - в приложении 6 бд, 2 из них "свои" (нужно мигрировать и все такое) и 4 "чужие" (приложение туда ходит напрямую просто как клиент). И вот не могу пока найти способ, как удобно разрулить несколько ентити менеджеров, чтобы не плодить бандлы.

Во, сам спросил, сам ответил) http://stackoverflow.com/a/15027134

а главное что поделился этим ответом с другими?

а главное что поделился этим ответом с другими?

?

Всем привет! Начинаю тут понемногу переписывать старый прототип на что-то нормальное, выбрал, соответственно, симфони. И столкнулся с такой проблемой - в приложении 6 бд, 2 из них "свои" (нужно мигрировать и все такое) и 4 "чужие" (приложение туда ходит напрямую просто как клиент). И вот не могу пока найти способ, как удобно разрулить несколько ентити менеджеров, чтобы не плодить бандлы.

А зачем тебе несколько em?

А зачем тебе несколько em?

Хм, а как мне иначе разделять ентити по разным бд?

может тут вообще есть 3й способ, как это лучше сделать :)

Хм, а как мне иначе разделять ентити по разным бд?

Так

А у тебя там точно сущности?

Ну точнее, точно ли там сущности, которыми должна оперировать(и менять!) твоя приложенька?

да

насчет остальных 4х не уверен, но вот в 2х бд да

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

Мммм

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

@fes0r расскажи человеку как ты делаешь "микросервисы" на симфони, оставляя монолит

Ась? ну есть такое

делаю)

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

JWT

я лично юзаю (апишки)

в json-ке токена вся необходимая информация для авторизации. И есть отдельный "модуль" который эти токены генерит

остальные токены берут из токена все что им надо (например нужно запомнить юзера - айдишку оттуда достают)

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

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

ну вот с вэбней не работал... в целом тоже самое должно быть. Аутентификацию просто стандартную юзаешь и все ок

тут мысль в другом

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

и я сейчас жестко убираю между ними пересечения границ модулей (когда например модуль A хочет сущности из модуля Б просто так)

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

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

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

вот недавно накидал

по поводу структуры проекта

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

норм

я еще по поводу изоляции модулей особо не писал там, это пока тип драфт

но в целом мысль - чем меньше пересечений границ - тем проще

годно короч

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

вложенность не плохо, просто пока можно надо ее избегать

ну и просто появитя модуль Comments

ну то есть внутри Products

или просто сущность

зависит от требований)

репозиторий им не нужон, VO не нужны особо

домен короч не отделяешь от фреймворка?)

вложенность не плохо, просто пока можно надо ее избегать

Вложенность это модуль, а модуль это хорошо) с flat выходит неконтролируемый спагетти код

домен короч не отделяешь от фреймворка?)

в смысле? Эти все штуки не знают ничего о фреймворке

Вложенность это модуль, а модуль это хорошо) с flat выходит неконтролируемый спагетти код

почитай внимательнее этот раздел

там не говорится "никогда не делайте вложенность"

почитай внимательнее этот раздел

Дома буду почитаю

там говорится "делайте вложенность только когда видите что это надо"

я думал Action/Doctrine специфичное для фрейма

а если Система оплаты, в ней разные способы оплаты и есть транзакция (платеж) ?

я думал Action/Doctrine специфичное для фрейма

Action - app level services Doctrine - элемент инфраструктуры Model - логика предметной области

а если Система оплаты, в ней разные способы оплаты и есть транзакция (платеж) ?

ну так это один модуль, а там далее если надо инверсией зависимости

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

ERROR: S client not available

Action - app level services Doctrine - элемент инфраструктуры Model - логика предметной области

ну я после уже понял, что Action это ты отвязанно размышляешь

ну в целом что то такое у sylius в виде компонент

https://github.com/Sylius/Sylius/tree/master/src/Sylius/Component

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

да, Core не ок

да, Core говно

назвали бы Infrastructure... вопросов бы небыло

Я обязательно прочитаю про жизненный цикл доктрины еще 10 раз, но проблема есть сейчас... Вот есть Lifecycle doctrine, тама есть: 1)prePersist 2)preUpdate\preRemove 3)postFlush 4)onClear Мне нужно отловить событие именно на СОЗДАНИЕ нового объекта, которого еще нет в базе данных. Предположительно нужно ловить preUpdate и смотреть, если объект еще не содержит ID, то он только создается.

Сейчас задача стоит, что есть в сущность implement IntegrationOneCInterface, то при создании нового объекта нужно чтобы листенер загружал из него данные в 1С.

И тоже самое с обновлением, чтобы 100% полная синхронизация была.

Запара на моменте с определением: доктрина будет делать INSERT или UPDATE.

prePersist/postPersist

А если допустим косяк и flush не будет выполнен после persist, либо будет ROLLBACK из-за ошибки и транзакция откатится в базе данных, а в 1С базу все добавится?

Как бы preUpdate норм, но он не работает соответственно на этапе создания, а не обновления

what

public function preFlush(PreFlushEventArgs $args) { $args->getEntityManager()->getUnitOfWork()->getScheduledEntityInsertions() }

Надеюсь не говно делаю

Но собака работает

Можно данным на обновление дать команду в очередь на обновление соответственно На удаление - в очередь на удаление На создание - в очередь на создание И все вешать на postFlush вообще

ОнФлуш

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

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

нипонял

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

точнее не увидел проблемы с flat

ну то есть... надо делаешь так как ты описал, не надо - не делаешь

если у тебя 3 стратегии - зачем их выносить

а если добавятся еще 5 - ну refactor -> move

я к тому что если стараться всегда делать flat то будет каша из модулей

я к тому что если стараться всегда делать flat то будет каша из модулей

потому есть другие принципы)

в частности L и I

это точно так же как coupling и coheasion