вложенные сущности

Обсуждаем, как правильно строить приложения
Ответить
Bio man
Сообщения: 609
Зарегистрирован: 2013.07.22, 10:40

вложенные сущности

Сообщение Bio man »

Подскажите, правильно ли я делаю...
Есть 2 сущности, Foo и Bar (являются агрегатами).
Foo содержит Bar, т.е. я могу получить Bar вызовом Foo->getBar().
И репозитории, FooRepo и BarRepo, FooRepo принимает в конструкторе BarRepo, что бы извлечь Bar при извлечении Foo.

Но закрались сомнения в таком подходе. Т.к. нужно знать, что FooRepo не будет сохранять Bar, если последний изменился. В таком случае нужно сперва сохранить Bar, а потом уже Foo.

Надеюсь не слишеом запутанно написал, если что, извиняйте.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: вложенные сущности

Сообщение zelenin »

репозиторий проносить в репозиторий не надо. это не будет эффективно в различных кейсах. строй все вокруг низкоуровневого соединения (DbConnection)
Bio man
Сообщения: 609
Зарегистрирован: 2013.07.22, 10:40

Re: вложенные сущности

Сообщение Bio man »

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

Насчет построения вокруг DbConnection не понял..
Bio man
Сообщения: 609
Зарегистрирован: 2013.07.22, 10:40

Re: вложенные сущности

Сообщение Bio man »

И еще, если не использовать репозиторий, то как мне знать какой источник данных используется для вложенной сущности?
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: вложенные сущности

Сообщение zelenin »

Bio man писал(а): 2018.02.03, 18:08 Но мне нужно сущность воссоздать, этим как-раз репозиторий и занимается.
несовсем. Создание сущности - это побочная функция и не определяющая для репо.
Репозиторий - это интерфейс для доступа к агрегатам определенного типа. Конечный, самый высокоуровневый, интерфейс. Bar в контексте BarRepo !== Bar в контексте FooRepo. Они могут работать по разным бизнес-правилам. Пример: при доступе к документации проекта рядовой сотрудник должен получить разрешение и записан в журнал учета, а директор может получать документацию напрямую без "логгирования". Вот это вот "логгирование" это бизнес-правило в рамках двух разных репозториев. И там и там мы получаем одно и то же, но в разных контекстах, по разным бизнес правилам. Поэтому некорректно юзать репо в репо.
Bio man писал(а): 2018.02.03, 18:08Насчет эффективности, я использую ленивую загрузку посредством генерации прокси. В сам прокси пробрасываю репозиторий, который дергает сущность при необходимости.
то есть ты передаешь BarRepo, чтобы передать в какой-то прокси-менеджер? Очень некорректно. Если это так, поясню.
Bio man писал(а): 2018.02.03, 18:08Насчет построения вокруг DbConnection не понял..
ну у тебя репо строятся на более низкоуровневом доступе к данным - AR/PDO/ORM итд.
Последний раз редактировалось zelenin 2018.02.03, 18:28, всего редактировалось 2 раза.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: вложенные сущности

Сообщение zelenin »

Bio man писал(а): 2018.02.03, 18:23 И еще, если не использовать репозиторий, то как мне знать какой источник данных используется для вложенной сущности?
контексты разные. Bar !== Bar в разных репозиториях. Например в репозитории отчетов, я бы предпочел получать Bar из денормализованной базы или голым sql.
Bio man
Сообщения: 609
Зарегистрирован: 2013.07.22, 10:40

Re: вложенные сущности

Сообщение Bio man »

Да, пробрасываю в прокси менеджер

Код: Выделить всё

$identity = $this->hydrator->hydrate(Identity::class, [
       'staffMember' => $this->factory->createProxy(StaffMember::class, function () use ($identityData) {
           return $this->staffRepository->getById(new StaffMemberId($identityData['staff_member_id']));
       }),
       ...
]);
Почему ты решил, что контексты разные? Все в 1 контексте.
Если в 2 словах, то суть такова:
identity рулит аутентификациейstaffMember'а (сотрудника). Я в презентационном слое посылаю команду логина, которая находит сотрудника и создает для него identity. Из команды возвращаю identity, из которого извлекаю id и записываю его в сессию, затем, извлекаю из identity сотрудника, оборачиваю в йишный Identity и делаю йиишный логин (user->login(new Identity($identity->getStaffMember()))).
Если бы я хранил в identity только ID сотрудника, то мне нужно было бы в презентационном слое дергать репозиторий что бы получить сотрудника, либо возвращать из команды оба этих объекта.
Надеюсь мысль ясна.
Bio man
Сообщения: 609
Зарегистрирован: 2013.07.22, 10:40

Re: вложенные сущности

Сообщение Bio man »

Задачу решил, обошелся просто сущностью Identity. И сделал так, что Identity хранит только ID сотрудника а не самого сотрудника.

Но все равно интересно получить ответ на предыдущее сообщение.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: вложенные сущности

Сообщение zelenin »

Bio man писал(а): 2018.02.03, 20:18 Задачу решил, обошелся просто сущностью Identity. И сделал так, что Identity хранит только ID сотрудника а не самого сотрудника.

Но все равно интересно получить ответ на предыдущее сообщение.
ну я все сказал. из предыдущего сообщения ничего не вынес.
контекст в разных репозиториях разный - это данность.
Bio man
Сообщения: 609
Зарегистрирован: 2013.07.22, 10:40

Re: вложенные сущности

Сообщение Bio man »

zelenin писал(а): 2018.02.03, 18:26
Bio man писал(а): 2018.02.03, 18:08Насчет эффективности, я использую ленивую загрузку посредством генерации прокси. В сам прокси пробрасываю репозиторий, который дергает сущность при необходимости.
то есть ты передаешь BarRepo, чтобы передать в какой-то прокси-менеджер? Очень некорректно. Если это так, поясню.
Вот этот момент ты так и не пояснил.

И почему в контексте может быть только 1 репозиторий? Получается, что в контексте должен быть 1 агрегат и 1 репозиторий?

Блин, надо найти время и почитать книжку по DDD, чтоб вас тут не терроризировать :)
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: вложенные сущности

Сообщение zelenin »

Bio man писал(а): 2018.02.03, 20:40И почему в контексте может быть только 1 репозиторий?
ты видимо решил что я про bounded context. Я про общепонятийный контекст) Контекст внутри репозиториев.
Bio man писал(а): 2018.02.03, 20:40
zelenin писал(а): 2018.02.03, 18:26
Bio man писал(а): 2018.02.03, 18:08Насчет эффективности, я использую ленивую загрузку посредством генерации прокси. В сам прокси пробрасываю репозиторий, который дергает сущность при необходимости.
то есть ты передаешь BarRepo, чтобы передать в какой-то прокси-менеджер? Очень некорректно. Если это так, поясню.
Вот этот момент ты так и не пояснил.
ну мне кажется, репо про прокси ничего знать не должен - это обязанность непосредственно орм. Ну и, как я сказал, может и допустимо репо в репо пихать, но это нарушает внутренний контекст репозиториев.
Ответить