Ну вот я как раз хотел сделать CommentableInterface, который имплементить во всех сущностях, которые можно комментировать. И уткнулся в то, с чего начал этот тред - как быть с setParent.
Покажите кусок кода/функции где у вас идет работа между комментом и альбомом например
Павел
Виктор
public function create(
AlbumComment|PhotoComment|TextComment $comment,
Request $request,
Album|Photo|Text $parent
): bool {
$this->form = $this->ff->createNamed(
'comment_form',
CommentFormType::class,
$comment
);
$this->form->handleRequest($request);
if ($this->form->isSubmitted()) {
$this->formSubmitted = true;
if ($this->form->isValid()) {
$comment->setParent($parent);
$comment->setAuthor($this->security->getUser());
$comment->setPublishedAt(new DateTimeImmutable());
$this->em->persist($comment);
$this->em->flush();
$this->formValid = true;
return true;
}
}
return false;
}
Павел
public function create(
AlbumComment|PhotoComment|TextComment $comment,
Request $request,
Album|Photo|Text $parent
): bool {
$this->form = $this->ff->createNamed(
'comment_form',
CommentFormType::class,
$comment
);
$this->form->handleRequest($request);
if ($this->form->isSubmitted()) {
$this->formSubmitted = true;
if ($this->form->isValid()) {
$comment->setParent($parent);
$comment->setAuthor($this->security->getUser());
$comment->setPublishedAt(new DateTimeImmutable());
$this->em->persist($comment);
$this->em->flush();
$this->formValid = true;
return true;
}
}
return false;
}
Т.е. симфони по union понимает какую сущность доставать? Или это не контроллер?
Павел
Кто достает Album|Photo|Text $parent ?
Виктор
Это не контроллер, CommentService.
Виктор
Метод вызывается из контроллеров для каждой сущности.
Виктор
А там уже одна сущность инжектится по slug.
Павел
Понятно. Ну сервис сам по себе уже не очень. Тем более в нем реквест
Павел
Это какое то объекдинение для копипаста в контроллере
Сергей
сервис знает про формы, их сабмит, про все виды комментов....
надо сервис переписать))
Павел
сервис знает про формы, их сабмит, про все виды комментов....
надо сервис переписать))
Судя по всему это DRY попытка, а не сервис)
Виктор
В двух словах, как это должно выглядеть?
Сергей
надо из комментов убрать знание о родителе. Либо сделать поле с типом родителя. Думаю поведение у всех комментов одинаковое, поэтому никаких дискриминаторов тут не нужно.
И просто в хендлере создавать коммент, передавая туда текст и id родителя.
Павел
В двух словах, как это должно выглядеть?
Если формы + сущность хз. Я бы наверное вообще такие сервисы не делал. Оставил как есть в контроллере. Без объединения и все было бы ок.
Разные сущности, разные экшены, че их объединять
Виктор
А как же DRY?) Или тут не тот случай? Получается, эта простыня в нескольких контроллерах.
Павел
А как же DRY?) Или тут не тот случай? Получается, эта простыня в нескольких контроллерах.
DRY не про попытку избавиться от одинаковых символов
Павел
Почитайте что такое DRY
Павел
Вы разделили на разные сущности, да у них похожее поведение, но раз разные сущности, то оно может быть и разным
Павел
Либо вы разделили на сущности не верно
Виктор
надо из комментов убрать знание о родителе. Либо сделать поле с типом родителя. Думаю поведение у всех комментов одинаковое, поэтому никаких дискриминаторов тут не нужно.
И просто в хендлере создавать коммент, передавая туда текст и id родителя.
Не понял, а как хранить связи? У меня же три сущности, к которым может относиться комментарий.
Павел
Виктор
Либо вы разделили на сущности не верно
Вероятно это. Я сейчас GoF пытаюсь осилить, и уже предполагаю, что нужно было какой-то GalleryEntity делать, а от него уже Album и Photo. И комментарии разделять не было бы нужно.
Павел
Не нужно весь код окутывать связями.
Павел
Павел
У вас крудиловака без логики и GOF
Павел
Если прикрутите получится плохо)))
Павел
Что уже выходит
Сергей
Не понял, а как хранить связи? У меня же три сущности, к которым может относиться комментарий.
Никак. Комменты получать запросом - просто в репозитории сделать метод findAllByParentId.
В идеале комменты вообще лучше вынести в отдельный модуль, слабо связанный с остальным проектом.
Но можно и не выносить. В любом случае в доменной области комменты тебе не нужны.
Виктор
У вас крудиловака без логики и GOF
Если честно, я хз тогда, как такое изучать)) Нужна же практика, а я хз, чё за проект нужен, чтобы это всё правомочно применять тогда)
Виктор
Никак. Комменты получать запросом - просто в репозитории сделать метод findAllByParentId.
В идеале комменты вообще лучше вынести в отдельный модуль, слабо связанный с остальным проектом.
Но можно и не выносить. В любом случае в доменной области комменты тебе не нужны.
Ок, у меня parent альбом с id 2 и parent фото с id 2. Как это разрешить?
Павел
Если честно, я хз тогда, как такое изучать)) Нужна же практика, а я хз, чё за проект нужен, чтобы это всё правомочно применять тогда)
Легко, не брать ТЗ как блог.
Возьмте кредитный калькулятор, на разные товары с разными стретагиями расчетов кредита, чтобы это можно было созлдавать, редактивароть, и вычислять динамически
The Ant
Не понял, а как хранить связи? У меня же три сущности, к которым может относиться комментарий.
Я так ещё не делал конешь. Но.
Смотри. Если юзать ууиды, то для таблицы комментов не нужны никакие связи. Тупо по ууид связного ресурса сохраняешь и все. В системе все ууиды будут уникальными. Поэтому обозначать дополнительно тип или ещё какой буллшит не надо.
Даёт возможность сделать отдельный модуль/сервис с комментами, которые сами по себе и ни от кого не зависят.
Павел
Я так ещё не делал конешь. Но.
Смотри. Если юзать ууиды, то для таблицы комментов не нужны никакие связи. Тупо по ууид связного ресурса сохраняешь и все. В системе все ууиды будут уникальными. Поэтому обозначать дополнительно тип или ещё какой буллшит не надо.
Даёт возможность сделать отдельный модуль/сервис с комментами, которые сами по себе и ни от кого не зависят.
Есть риск проипаться с уникальностью ууид, даже в рамках одной таблицы, не говоря уже нескольких. Лучше тип добавлять
Сергей
Ок, у меня parent альбом с id 2 и parent фото с id 2. Как это разрешить?
ну раз айдишники автоинкремент, значит нужно в комментах еще поле с типом родителя.
Павел
Когда в рамках одной - там гарантия уникальности, а когда уже несколько таблиц - такой гарантии нет
Виктор
ну раз айдишники автоинкремент, значит нужно в комментах еще поле с типом родителя.
Так это же и получается дискриминатор, по сути. Нет?
Виктор
Механика та же.
The Ant
Есть риск проипаться с уникальностью ууид, даже в рамках одной таблицы, не говоря уже нескольких. Лучше тип добавлять
Крайне мал. Ууид7 какой сделать. Если постинг очень высокий, буквально тыщи в секунду то да, могут быть коллизии
Павел
Крайне мал. Ууид7 какой сделать. Если постинг очень высокий, буквально тыщи в секунду то да, могут быть коллизии
Мал не мал, есть же. Лучше тип добавить как говорил Сергей выше
Сергей
Так это же и получается дискриминатор, по сути. Нет?
дискриминатор - это объектная штука - позволяет твои энтити наследовать..
А тебе тут наследование не нужно. Достаточно просто поле с типом и id родителя хранить
The Ant
Мал не мал, есть же. Лучше тип добавить как говорил Сергей выше
Ууид7 основан на времени, практически невозможен )
Павел
Я так ещё не делал конешь. Но.
Смотри. Если юзать ууиды, то для таблицы комментов не нужны никакие связи. Тупо по ууид связного ресурса сохраняешь и все. В системе все ууиды будут уникальными. Поэтому обозначать дополнительно тип или ещё какой буллшит не надо.
Даёт возможность сделать отдельный модуль/сервис с комментами, которые сами по себе и ни от кого не зависят.
Опять же если нет типа, как ты поймешь с какой сущностью связь many to one. Ходить по всем таблицам в поисках нужного?
The Ant
Опять же если нет типа, как ты поймешь с какой сущностью связь many to one. Ходить по всем таблицам в поисках нужного?
Об этом и говорю, связь не нужна. Запрашиваешь комменты по иду сущности отдельным запросом.
Павел
Об этом и говорю, связь не нужна. Запрашиваешь комменты по иду сущности отдельным запросом.
А понял. А если в обратную сторону?)
Павел
Нужно понять какой родитель у коммента
The Ant
Если все таки раз в столетие случится коллизия, так ли важно для коммета, если он не добавится? И понадобится повтор написания? Мне кажется пофигу )
Виктор
Нужно понять какой родитель у коммента
Ну у меня так как раз. Есть "последние комментарии", у каждого ссылка на свою сущность. То есть нужно, чтобы связь двусторонняя была. И тут этот вопрос актуален.
Павел
Зачем? По моему опыту это почти никогда не надо
например коммент удаляется, надо кинуть ивент, чтобы перерасчитать количество комментов у сущности)
Павел
Короче лишний возможный гемор не понятно с каким профитом. Тип нужен
Павел
Ну у меня так как раз. Есть "последние комментарии", у каждого ссылка на свою сущность. То есть нужно, чтобы связь двусторонняя была. И тут этот вопрос актуален.
Вы делаете просто через сущности все, поэтому везде накидываете связи. Можно работать без связей доктрины
The Ant
например коммент удаляется, надо кинуть ивент, чтобы перерасчитать количество комментов у сущности)
Тип тоже не даст ответа для какой сущности ивент кинули. Будешь во всех проверять
Павел
Тип тоже не даст ответа для какой сущности ивент кинули. Будешь во всех проверять
Как же.
CommentRemoved(id, type, parentId)
Каждая сущность да, проверит тип (тупо эквивалетность стрингов). Но она хотя бы может определить. Как будешь ты делать вообще хз. Искать в БД есть ли parentId? И так например 10 сущностей, все будут искать parentId?
Павел
Короче ты предлагаешь сложности без профита.
Павел
Причем сам какой то профит не предлагаешь
The Ant
Профит сомнительный да. Отсутствие лишней колонки. Простой пк 🤷
Повторю сам так не делал. Это типа "что если?" 😄
Но опять же. Этот счётчик нужен? М.б. из комментов получать инфу о количестве. Кешить тупо этот счётчик.
The Ant
Так-то для твоего ивента придется связи обозначать, а это каплинг получится
Павел
Профит сомнительный да. Отсутствие лишней колонки. Простой пк 🤷
Повторю сам так не делал. Это типа "что если?" 😄
Но опять же. Этот счётчик нужен? М.б. из комментов получать инфу о количестве. Кешить тупо этот счётчик.
Ну смотри, ты ишешь варианты как рещить проблему, которая образовалась твоим решением))
The Ant
В монолите мб и пофиг, а в модульном монолите уже межмодульное взаимодействие
Павел
Так-то для твоего ивента придется связи обозначать, а это каплинг получится
Можно кидать и разные ивенты
Павел
В монолите мб и пофиг, а в модульном монолите уже межмодульное взаимодействие
Какой каплинг? Ивенты - это межмодульное взаимодейсвтие в том числе
Павел
Модули и так и так должны общаться, без этого никак
The Ant
Какой каплинг? Ивенты - это межмодульное взаимодейсвтие в том числе
Каплинг в связях сущностей.
Павел
Или через синк или через шину
Павел
Там просто string type, string parentId
Павел
Как не будет? Тип же заставит связь эту сделать
string не дает связь. С таким же успехом я могу скахать, что твой id тоже связь)
Павел
Ну или enum
The Ant
Это плохо для поддержки. Как минимум константа будет
The Ant
Или енам да
The Ant
Литералом точно нет )