SP
Я думаю что ты хотел придумать какую-то аналогию про ссылки а так опять не понимаю к чему ты.
С точки зрения ссылок на объект репозиторий и коллекция не особо отличаются
С точки зрения ссылок на объект репозиторий и коллекция не особо отличаются
Size: a a a
2020 October 21
МФ
Если ты хочешь весь лук продать соседу, то ты свяжешь большую связку из всего лука в сарае и отдашь её соседу. Но сарай останется у тебя, хоть и пустой
Достаём лук, но не достаём... :) чудеса какие в сарае происходят
AC
Достаём лук, но не достаём... :) чудеса какие в сарае происходят
Может это вовсе на сарай? Выглядит как лампа джина изнутри
DE
Поэтому есть стационарный сарай, есть переносимый ящик, а есть контейнер, который одновременно является и сараем, и ящиком.
DE
Так и репозиторий. Является хранилищем, но выглядит как коллекция.
AP
Если ты хочешь весь лук продать соседу, то ты свяжешь большую связку из всего лука в сарае и отдашь её соседу. Но сарай останется у тебя, хоть и пустой
Связка лука и сарай в данном контексте могут иметь один интерфейс и клиенту будет все равно откуда брать лук
DE
Связка лука и сарай в данном контексте могут иметь один интерфейс и клиенту будет все равно откуда брать лук
Он про передачу самой коллекции. Ящик new Box(items) мы можем создать и передать в рендерер как объект-значение. А сам сарай обычно не можем или не хотим, так как это обычно заинжекченный сервис.
DE
Но в любом случае возвращать из геттера и/или передавать куда-то саму оригинальную мутабельную коллекцию доменных объектов пахнет риском нарушения инкапсуляции и избыточностью, так как стороне чтения методы add и remove ни к чему.
Поэтому всё равно корректнее возвращать или передавать куда-то массив или итератор.
Поэтому всё равно корректнее возвращать или передавать куда-то массив или итератор.
E
Кстати, почти по теме.
Если у нас есть DTO что в себе хранит идентификаторы объектов в репозитории. Корректно ли реализовать в DTO методы что достают эти объекты из репозитория когда сам репозиторий в сигнатуре метода как зависимость выставляется?
Мне показалось это чище из-за того, что примитивный тип идентификатора - такой себе контракт чтобы его доставать из DTO и уже снаружи решать как выудить из репозитория сущность.
Если у нас есть DTO что в себе хранит идентификаторы объектов в репозитории. Корректно ли реализовать в DTO методы что достают эти объекты из репозитория когда сам репозиторий в сигнатуре метода как зависимость выставляется?
Мне показалось это чище из-за того, что примитивный тип идентификатора - такой себе контракт чтобы его доставать из DTO и уже снаружи решать как выудить из репозитория сущность.
E
Аля аксессоры с зависимостями
SB
Кстати, почти по теме.
Если у нас есть DTO что в себе хранит идентификаторы объектов в репозитории. Корректно ли реализовать в DTO методы что достают эти объекты из репозитория когда сам репозиторий в сигнатуре метода как зависимость выставляется?
Мне показалось это чище из-за того, что примитивный тип идентификатора - такой себе контракт чтобы его доставать из DTO и уже снаружи решать как выудить из репозитория сущность.
Если у нас есть DTO что в себе хранит идентификаторы объектов в репозитории. Корректно ли реализовать в DTO методы что достают эти объекты из репозитория когда сам репозиторий в сигнатуре метода как зависимость выставляется?
Мне показалось это чище из-за того, что примитивный тип идентификатора - такой себе контракт чтобы его доставать из DTO и уже снаружи решать как выудить из репозитория сущность.
так срдки сделать спец тип для каждого (ну или через дженерик один реализовать)
E
@GDXbsv это пых 😐
E
скалярки только врапать, а генерики только костылять)
EE
Подскажите материал по модульному программированию.
EE
Книги, статейки или сурсы
СП
Добрый день!
Есть вот такой код:
Это нормально рассчитывать на магию ORM и ссылок на объекты?
Есть вот такой код:
// Получили сущность из репозитория
$entity = $entityRepository->get(1);
$entity->getName(); // null
// Отрпавили в команду ID, команда произвела манипуляции с объектом и сохранила его в репозитории,
// Например, установила свойство $entity->name = "x".
$command->handle($entity->id);
$entity->getName(); // "x"
Это нормально рассчитывать на магию ORM и ссылок на объекты?
SP
Добрый день!
Есть вот такой код:
Это нормально рассчитывать на магию ORM и ссылок на объекты?
Есть вот такой код:
// Получили сущность из репозитория
$entity = $entityRepository->get(1);
$entity->getName(); // null
// Отрпавили в команду ID, команда произвела манипуляции с объектом и сохранила его в репозитории,
// Например, установила свойство $entity->name = "x".
$command->handle($entity->id);
$entity->getName(); // "x"
Это нормально рассчитывать на магию ORM и ссылок на объекты?
нет)
AL
Добрый день!
Есть вот такой код:
Это нормально рассчитывать на магию ORM и ссылок на объекты?
Есть вот такой код:
// Получили сущность из репозитория
$entity = $entityRepository->get(1);
$entity->getName(); // null
// Отрпавили в команду ID, команда произвела манипуляции с объектом и сохранила его в репозитории,
// Например, установила свойство $entity->name = "x".
$command->handle($entity->id);
$entity->getName(); // "x"
Это нормально рассчитывать на магию ORM и ссылок на объекты?
а зачем тебе такое?
СП
а зачем тебе такое?
Ну есть команда, в одних местах вызывается с ID, а в других есть сущность)
SP
Добрый день!
Есть вот такой код:
Это нормально рассчитывать на магию ORM и ссылок на объекты?
Есть вот такой код:
// Получили сущность из репозитория
$entity = $entityRepository->get(1);
$entity->getName(); // null
// Отрпавили в команду ID, команда произвела манипуляции с объектом и сохранила его в репозитории,
// Например, установила свойство $entity->name = "x".
$command->handle($entity->id);
$entity->getName(); // "x"
Это нормально рассчитывать на магию ORM и ссылок на объекты?
это как "нормально ли глобальные переменные". Читай про pathalogical coupling