ну то есть если у тебя сущность сложная

то лучше заводить отдельную фабрику/билдер которая уже будет знать как собрать сущность

так и запутаться меньше шансов и логику проще проверять и тестить

по сути хэндер это такая штука которая декларирует просто последовательность действий. Сам он ничего не умеет - он менеджер. умеет только делигировать

В данном случае, да. Я там собрал сущность на основе данных из запроса, передал в метод репозитория, он вставил запись. Все верно?

Более интересно, куда вынести обновление данных, если по хорошему, репозиторий для этих целей не подходит.

Более интересно, куда вынести обновление данных, если по хорошему, репозиторий для этих целей не подходит.

а вот тут поподробнее

почему не подходит?

ну то есть у тебя нет сущностей? тогда у тебя должен быть какой-то gateway который скрывает весь sql

почему не подходит?

ну если смотреть со стороны collection like-репозиториев, то там нет сохранения данных

ну если смотреть со стороны collection like-репозиториев, то там нет сохранения данных

а ты об этом

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

и тогда тебе надо мутить какой-то детектор изменений на стороне репозитория (unit of work)

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

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

ну у тебя изменения в связях это тоже изменения

их тоже можно трэкать

Давай на примере? есть у меня 2 сущности, филиалы и операторы. 1) class Office { $id, $name, $operator } 2) class Operator { $id, $name } Имеем репозиторий офиса: DoctrineOfficeRepository { func add(Office $office) {} } Теперь при добавлении, я делаю нечно такое в комманде: class AddOfficeCommand { func __construct(array $requestData) {...} func handle(IOfficeRepository $repo) { $office = new Office(); $office->setName($this-> requestData['foo']); $office->assignOperator(new Operator($this->requestData['operator_id'])); $repo->add($office); } } затем, хочу делать апдейт записи и обновить название офиса и привязать другого оператора. Как это сделать используя UoW? Где будет логика запроса в базу?

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

в конце хандла $uow->flush()

> но в нем никак нет логики для обновления записи там есть вычисление изменений. Зная это ты можешь сформировать sql

$uow->compitudeEntityChangeSet()

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

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

смотри исходники доктрины)

или просто почитай про UoW

или просто почитай про UoW

уже обчитался =\

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

получается для каждого объекта домена, свой UoW?

нет, в uow все сущности

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

скорее всего это ошибка и(или) костыли

Попробую зайти с другой стороны. По порядку. Я получил массив параметров из запроса. Далее мои действия - собрать из этого entity-объект? (я говорю про апдейт записи, но пока до этого не добрались)

$office = new Office($request->name, $request->foo); $repo->add($office); $em->flush();

$office = $repo->findOneById($request->id); $office->hire($employee); $em->flush();

при $em->flush() происходит что. Данные из сущности дегидрируются (по сути достаются) и сравниваются с тем что было при fetch.

работает это за счет того что в системе никогда не должно быть более одного инстанса сущности с каким-то ID (Identity Map)

для связей - one-to-one трекать легк

при $em->flush() происходит что. Данные из сущности дегидрируются (по сути достаются) и сравниваются с тем что было при fetch.

ну и также еще есть те, которые добавились и те, которые надо удалить

для many-to можно трекать изменения через коллекции

так там просто обходом графа собирается все дерево и сравнивается

а, или обходом там выбирается порядок апдейтов

ну это в любом случае деталь реализации доктрины)

гм, если $em->flush() выносить за пределы репозитория, то ведь хрен потом подменишь на InMemoryRepository какой-нить

почему?

а, в смысле что надо еще em отключить будет?

угу

ну да

Видел, как делают репозитории и flush пихают внутрь. Так, вроде, ведь правильнее - код не зависит от доктрины.

слабо представляю, как это поможет

не на find же flush делать :)

ну нет, только на add/remove

$office = $repo->findOneById($request->id); $office->hire($employee); окей, привязали $employee, затем как мне тут поможет UoW?

$uow->registerUpdate($office); $uow->commit(); ?

я вместо uow там писал em

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

в итоге тебе где-то в контроллере или чем-то похожем в конце твоих транзакций надо делать коммит

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

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

нет, апдейт тоже абстрагирован, потому что вообще не трогает репозиторий

Т.е. вот так, уже все абстрагировано? $data = $entityManager->getRepository('ATest')->findOne(1); // ATest is my entitity class $data->name = "ORM Tested"; // just change the name $entityManager->persist($data); $entityManager->flush();

ну точнее добавление и удаление ничем не отличаются от обновления

Т.е. вот так, уже все абстрагировано? $data = $entityManager->getRepository('ATest')->findOne(1); // ATest is my entitity class $data->name = "ORM Tested"; // just change the name $entityManager->persist($data); $entityManager->flush();

убери persist

merge?

он вообще не нужен нигде кроме репозитория

merge?

нет, только flush

он вообще не нужен нигде кроме репозитория

не понял, в смысле?

ты persist делаешь только в методе add репозитория и все

я еще больше запутался, как тогда данные обновятся

ERROR: S client not available

на flush entity manager спросит у uow "а что у тебя обновилось?" как описывал Сергей

и обновит

т.е. где-то в findOne есть вотчер UoW?

Видел, как делают репозитории и flush пихают внутрь. Так, вроде, ведь правильнее - код не зависит от доктрины.

это типа мега херова

да, где-то в find*/add/remove есть $uow->watch/markAsAdded/markAsRemoved

это типа мега херова

flush в репозитории?

он вообще не нужен нигде кроме репозитория

он ВООБЩЕ не нужен

ну то есть не нужно делать detach

он ВООБЩЕ не нужен

так в add

ну или чем-то таком

там persist

а не merge

так я про persist говорил)

а ну это да)

Т.е. вот так, уже все абстрагировано? $data = $entityManager->getRepository('ATest')->findOne(1); // ATest is my entitity class $data->name = "ORM Tested"; // just change the name $entityManager->persist($data); $entityManager->flush();

абстрагируйся от баз данных. Представь что у тебя есть какой-то in-memory storage

-

find - достает референс на объект

persist - добавляет объект в сторадж

flush - сохраняет весь граф объектов крутящихся в in memory хранилище в базу или на диск или куда там тебе надо

flush обозначает границу бизнес транзакции, границу юзкейса

по хорошему flush должен делать декоратор над шиной команд

окей хорошо, куда обернуть вот это: $data = $entityManager->getRepository('ATest')->findOne(1); // ATest is my entitity class $data->name = "ORM Tested"; // just change the name $entityManager->flush(); Если я не хочу зависеть от доктрины, а заюзать например Eloquent?

окей хорошо, куда обернуть вот это: $data = $entityManager->getRepository('ATest')->findOne(1); // ATest is my entitity class $data->name = "ORM Tested"; // just change the name $entityManager->flush(); Если я не хочу зависеть от доктрины, а заюзать например Eloquent?

то тебе не нужен репозиторий

то тебе нужна другая реализация flush :)

Eloquent = Active Record

Eloquent = Active Record

да-да, богомерзкая хренота

Eloquent = Active Record

так все равно норм можно намапить

то есть у тебя есть data model (не сущность) и у нее есть save

да-да, богомерзкая хренота

не в этом дело

так все равно норм можно намапить

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

ты моешь вжахнуть UoW который просто будет обходить граф объектов и оркестрировать save-ами

но не более