за этой логикой сложно следить если сильно размазывать по ивентам
ну как... сама по себе логика не будет размазываться по ивентам. Ивенты будут своего рода точками входа.
Sergey
Sergey
связь между контекстами
Sergey
ну и ивенты будут сначала собираться в сущностях и тригериться только по успешному коммиту транзакции в базу
invariance
тут случайно нет людей, которые шарят в алгоритмах?
Ale
Зависит от алгоритмов)
invariance
😆
invariance
Sergey
Marat
invariance
Какой варик быстрее: заполнять бинарное дерево до полного пустыми значениями и юзать одномерный массив для хранения, или юзать неполное бинарное дерево, но заполнять двумерный массив?
Sergey
invariance
цель - выбрать наиболее быстрый вариант D:
Sergey
окей, дерево зачем тебе?
Sergey
ну мол... немного непонятно из описания что ты вообще хочешь сделать и как ты себе представляешь бинарное дерево состоящее из пустых значений
Sergey
в этом же смысла нет
invariance
Есть, можно юзать одномерный массив для хранения
invariance
в полном бинарном дереве каждый новый уровень всегда вдвое больше предыдущего
Ale
да, вопрос выше правильный
invariance
поиск например
Ale
поиск числа в дереве?
Ale
пирамида?
Ale
красно-черное?
Ale
если просто от балды собранное дерево, то какая разница если все элементы смотреть надо)
Sergey
поиск например
поиск разный бывает. И на выбор алгоритмов и структур влияет характер данных и поиска.
invariance
да
Alexander
Если только поиск то подумай о хеш таблицах еще.
🐴
Дайте-ка я побрежу. Есть набор моделей, например Author, Topic, Comment etc. Они могут быть в отношениях, довольно сложных, например Comment отновится к определенному Topic, и у него есть Author. Конструкции типа comment.getTopics[0].getAuthor.getFolowers понятно нарушают LOD. Может быть тогда вообще сделать так, чтобы сущности не знали друг про друга? У Comment не будет методов вроде getTopic() или getAuthor().
🐴
А информация о связях, например, будет храниться отдельно. как-то. Не знаю, как.
Sergey
может тебе не надо просто гидрировать данные на сущность?)
Sergey
ну то есть.... что ты сделать хочешь? Подготовить данные для UI?
🐴
а как надо?
🐴
ну да
Sergey
ну сделай выборку, жазни все в ArrayHydrator какой
Sergey
и радуйся
Sergey
не надо париться о LOD)
Sergey
не надо париться с геттерами
🐴
мне надо нарисовать клиенту сложную структуру типа комменты, их авторы, какие-то данные об авторах, может быт еще что-то
Sergey
ну так, идеальный кейс для такой штуки как SQL)
Sergey
ну просто через query builder выбираешь те данные которые тебе нужны
🐴
получается у меня DB mapper будет возвращать некий сложный массив?
Sergey
и говоришь ему в getResult что бы не ObjectHydrator юзало а ArrayHydrator
🐴
и этот массив отправится прямо во вью?
Sergey
ну тип того
Sergey
еще ты можешь в select писать штуки вроде select new MyViewDTO(author.id)
Sergey
но я этим пока не пользовался особо(
Sergey
насколько я понял такое работает хорошо для простых данных
Sergey
но это если ты хочешь загоняться
Sergey
если надо оч быстро запилить - вариант с нарушением LoD будет намного быстрее
Sergey
эдакий прототип
🐴
прототип у меня уже работает
🐴
щас фаза рефакторинга
Sergey
ну я хз... было б неплохо выслушать других людей
Sergey
потому что то о чем я тебе вещаю это мой бзик последние пару месяцев
Sergey
и я еще не наступил с ним на грабли но допускаю что они где-то там... впереди
🐴
чуть более в сторону вопрос: зачем вообще моделям знать о своих связях?
🐴
зачем Comment знать о своем Author?
Sergey
что бы построить агрегат сущностей
Sergey
public function comment(string $message, User $author)
{
$this->comments->add(new Comment($message, $author);
}
Sergey
ну то есть без связей такое сделать не получится особо
Sergey
а потом можно накладывтаь на это добро бизнес ограничения
Sergey
вроде "только один автор может постить в этот топик"
Sergey
if ($this->comments->matching(Comment::byAuthorCriteria($author)) {
throw new MultimpleCommentsNotAllowed($author, $topic)l
}
🐴
а почему агрегат не может знать о связях? ну типа $comenter = new PostCommenter($post); $commenter->comment($text, $date)
Sergey
посмотри на мой кейс
Sergey
если бы коммент не знал об авторе
Sergey
ты бы не смог сделать такую выборку как у меня в примере
Sergey
их сущности Topic по коллекции комментов по отдельной критерии
Sergey
ну то есть связи важны. Их количество нужно минимизировать, но в случае авторов-комментов она хотя бы с одной стороны должна быть. И логичнее ее размещать у коммента
Sergey
односторонюю
Sergey
не?
🐴
смотрю, не понимаю, почему это же самое не реализовать в PostCommenter
Sergey
а почему агрегат не может знать о связях? ну типа $comenter = new PostCommenter($post); $commenter->comment($text, $date)
агрегат - это граф и у него есть корень
Sergey
через корень агрегата происходят все операции над ним
Sergey
смотрю, не понимаю, почему это же самое не реализовать в PostCommenter
ну потому что... тогда зачем тебе доктрина и сущности вообще?) юзал бы dao какой-нибудь
🐴
а у меня и нет доктрины
Sergey
а сущности тогда откуда?