Более того класс UserRecord может вообще не существовать в дев окружении, а генерироваться только при сборке. И вызвать его напрямую не получится.

ну это уже не yii

Ну тогда у меня "Претензия только одна: я пришел в ваш код и вызвал User::save() напрямую и пропали наши доменные ивенты"

отправка событий привязана к коммиту uow

так что если ты закоммитил изменеия - собираешь ивенты и впуть

Ну тогда у меня "Претензия только одна: я пришел в ваш код и вызвал User::save() напрямую и пропали наши доменные ивенты"

*Еще раз ты не изменил агрегат. Ты изменил запись в базе напрямую. Ивентов нет и это правильно*

Сами себе противоречите. К чужому коду притензии предъявляете, что ивентов нет, а в своем "так и должно происходить" при одинаковой обстановке

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

Сами себе противоречите. К чужому коду притензии предъявляете, что ивентов нет, а в своем "так и должно происходить" при одинаковой обстановке

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

отправка событий привязана к коммиту uow

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

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

ты в команде не работал никогда-чтоли?

Еще раз перечитай. То что ты сделал равносильно тому что $pdo->update(...). Это никто в здравом уме (даже джун) в коде приложения делать не будет.

Еще раз перечитай. То что ты сделал равносильно тому что $pdo->update(...). Это никто в здравом уме (даже джун) в коде приложения делать не будет.

будет)

я видел)

я видел)

Делал?)

Ну тогда вон с профессии и делов

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

к примеру я поменял email и должен сработать триггер на его изменение. Создать в очереди job, оттуда на почту email прислать для подтверждения

к примеру я поменял email и должен сработать триггер на его изменение. Создать в очереди job, оттуда на почту email прислать для подтверждения

ну окей, если ты поменял минуя приложение - как оно об этом узнает?

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

при том что в AR есть лайфсайкл ивенты на худой конец которые позволяют привязать эту логику

Ну и менять ты его будешь у сущности User, а не у объекта UserRecord

прикол в том что в том варианте который предлагает Антон у тебя нет доступа к UserRecord напрямую, только через User

весь прикол в том что ровно так же, как вместо репозитория за сохранение релейшенов отвечают бихейверы, можно полностью отказаться от репозитория

он просто вызывает save

туда же можно запихнуть и логику публикации доменных событий

и мы избавляемся от лишней абстракции

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

но это уже другая история

вот если бы Дмитрий в репозитории разруливал граф зависимостей сущностей

Нет я понимаю что это можно решать соглашениями и прочее, но зачем если это не сложно явно выразить в коде?

На улице снег, а мои лыжи не едут Если есть возможность вызвать User::save() напрямую в yii2-demo-shop - это плохо написанный код, ведь это не сложно явно выразить в коде А когда я делаю в твоем коде User::save() напрямую, при чем естественно пропадают доменные ивенты - это в норме Сорян, но я хочу прекратить эту дискуссию)

и сохранял бы все так, что бы не нужно было кастылей в духе $files = $this->files;...

и запретил бы сохранение сущностей вне контекста репозитория

вот тогда да, смысл был бы

На улице снег, а мои лыжи не едут Если есть возможность вызвать User::save() напрямую в yii2-demo-shop - это плохо написанный код, ведь это не сложно явно выразить в коде А когда я делаю в твоем коде User::save() напрямую, при чем естественно пропадают доменные ивенты - это в норме Сорян, но я хочу прекратить эту дискуссию)

Не будет в моем коде User::save()! Просто не будет такого метода у объекта User. Будет только одна возможность сохранить пользователя: комит UoW

На улице снег, а мои лыжи не едут Если есть возможность вызвать User::save() напрямую в yii2-demo-shop - это плохо написанный код, ведь это не сложно явно выразить в коде А когда я делаю в твоем коде User::save() напрямую, при чем естественно пропадают доменные ивенты - это в норме Сорян, но я хочу прекратить эту дискуссию)

ты не можешь в его коде сделать User::save

вот и вся разница)

меня всегда коробило то, что сущность/агрегат (похеру) знает как себя сохранять...

меня всегда коробило то, что сущность/агрегат (похеру) знает как себя сохранять...

?

в смысле "знает"

User::save

не, это удобно

У Максима жесткое неприятие AR :)

хорошо жить когда у тебя есть готовые дата мэпперы

удобно?) удобно не заниматься хернёй с ООП)

и ддд следом

а когда у тебя легаси, или когда мы попали в 2008-ой?

ты не можешь в его коде сделать User::save

мы же про AR говорим? if ($user = UserRecord::findByEmail($email)){ $user->email = $newEmail; $user->save() } Что у меня в $user?

У него AR только для чтения, нет?

Именно

мы же про AR говорим? if ($user = UserRecord::findByEmail($email)){ $user->email = $newEmail; $user->save() } Что у меня в $user?

save не будет

слово удобно - оно плохое) оно субъективное и кому-то удобно ю2 использовать, потому что он не заставляет мозги использовать) удобно же)

Два класса: User и UserRecord

У User никаких save нету.

Именно

Т.е. в приложениях на yii2 ты бы тело save переопределял на {}?

слово удобно - оно плохое) оно субъективное и кому-то удобно ю2 использовать, потому что он не заставляет мозги использовать) удобно же)

плюсы и минусы можешь рассматривать. Ты заипешься свой дата мэппер сделать, с делать схему как предлагает Антон довольно просто

Претензия только одна: я пришел в ваш код и вызвал User::save() напрямую и пропали наши доменные ивенты. Ваш "репозиторий" (вообще то это скорее фасад если его задача только скрыть внутренние вызовы) никак не защищает от этого. Вариант с отдельной моделью решает такой кейс.

А я пришёл в ваш код и запорол агрегат через рефлексию или анонимку потому что "PHP это позволяет". Значит код тоже дырявый. Смысл в том, что технические обходные пути есть всегда. Это всегда контролируется только дисциплинарными методами.

А я пришёл в ваш код и запорол агрегат через рефлексию или анонимку потому что "PHP это позволяет". Значит код тоже дырявый. Смысл в том, что технические обходные пути есть всегда. Это всегда контролируется только дисциплинарными методами.

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

А я пришёл в ваш код и запорол агрегат через рефлексию или анонимку потому что "PHP это позволяет". Значит код тоже дырявый. Смысл в том, что технические обходные пути есть всегда. Это всегда контролируется только дисциплинарными методами.

Я это упоминал вышел. Технические пути есть всегда.

хотя сделать плохо всегда проще чем хорошо...

все тлен

Приходит кто-то на проект, получает задачу сделать метод изменения email пользователя. Открывает класс User и такой смотрит, а у нас тут ActiveRecord, ну ок сделаю экшен: $user = User::find($id); $user->email = $email; $user->save();

стильно, модно, молодёжно)

Про то что там какие-то репозитории есть чтобы получить/cохранить пользователя и это правильный путь на проекте откуда он узнает?

Антон, ну на само деле проблема то в другом

это можно в ридми написать

типа "нюанс - юзайте репозиторий"

Ну я сейчас тоже утрирую понятно

меня лично больше смущает другое

Про то что там какие-то репозитории есть чтобы получить/cохранить пользователя и это правильный путь на проекте откуда он узнает?

Т.е. ему проект не дают, но написать код просят? Откуда он узнает )))

ERROR: S client not available

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

Т.е. ему проект не дают, но написать код просят? Откуда он узнает )))

ты видимо никогда не работал с легаси

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

ну или ты просто желаешь ему смерти)

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

Так я за то и топлю что если можно дешего отделить доменную логику от костылей, то почему бы и да?

Прекратите это ты не знаешь ты видимо не видел ...

ну ты реально не знаешь и не видел) в каждом слове читается то, что ты не понимаешь о чём тебе по кругу уже 3й час втирают)

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

И что, если умер? Код ему дают и изучить его нужно, перед написанием чего-то?

у меня был проект на 200 метров кода с файлами на 7 тысяч строк условных операторов, завёрнутых в свитч/кейсы) иди, разбирайся)

Прекратите это ты не знаешь ты видимо не видел ...

ну а ты начни анализировать, да, я понимаю что тут много утрируют, переоценивают значение проблем, и что это все далеко не самый худший код который можно увидеть на yii. я бы даже сказал что все не плохо. Меня только смущают кастыли которые находятся далеко по коду от причин этих кастылей, и то что прикрываются абстракциями и solid

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

Сложнее... проще... Нашли проблему... Вешаем хук со статическим анализатором в git и джун резко перевоспитывается.

Сложнее... проще... Нашли проблему... Вешаем хук со статическим анализатором в git и джун резко перевоспитывается.

то есть ты не видишь проблемы с кастылем что бы отработал __set?

По моему опыту выходит что количество костылей увеличивается с каждым слоем в любом случае. В доменном их минимум и стараемся как можно лучше его вычистить. В апликейшн уже больше, и иногда их сложно решить. Персистенс обычно полный п... если у нас не ES конечно

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

если ты настроил его нормально

если ты настроил его нормально

иии если это не phpstan :D

По моему опыту выходит что количество костылей увеличивается с каждым слоем в любом случае. В доменном их минимум и стараемся как можно лучше его вычистить. В апликейшн уже больше, и иногда их сложно решить. Персистенс обычно полный п... если у нас не ES конечно

у меня сча ES на паре сущностей и это... удобно)

иии если это не phpstan :D

не, речь идет про всякие deptrac

ну и в соседнем чате один человек говорит что у него моих проблем с phpstan нет

посмотрю,спасибо)

ну а ты начни анализировать, да, я понимаю что тут много утрируют, переоценивают значение проблем, и что это все далеко не самый худший код который можно увидеть на yii. я бы даже сказал что все не плохо. Меня только смущают кастыли которые находятся далеко по коду от причин этих кастылей, и то что прикрываются абстракциями и solid

Меня возмутила его ТОЛЬКО ОДНА ПРЕТЕНЗИЯ В yii2 у модели чтоб не было save()??? Какой-то нонсонс, который все поведения сломает

Меня возмутила его ТОЛЬКО ОДНА ПРЕТЕНЗИЯ В yii2 у модели чтоб не было save()??? Какой-то нонсонс, который все поведения сломает

ты упрощаешь суть притензии

у меня сча ES на паре сущностей и это... удобно)

Меня сейчас в ES смущает только одно, сложность проектирования агрегатов под большие данные

Меня возмутила его ТОЛЬКО ОДНА ПРЕТЕНЗИЯ В yii2 у модели чтоб не было save()??? Какой-то нонсонс, который все поведения сломает

Претензия не yii, а к бесполезному классу. У нас уже есть save у модели, надо смирится что это ActiveRecord и превращать это в плюс. А не выдумать классы ради мнимой инкапсуляции.

Меня возмутила его ТОЛЬКО ОДНА ПРЕТЕНЗИЯ В yii2 у модели чтоб не было save()??? Какой-то нонсонс, который все поведения сломает

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

Тему предлагаю закрыть. Уже скучно. Давайте вот лучше за какие CommandBus и Саги понакидываем.

там у Дмирия в какой-то из статей вроде описывались отдельные персистеры - и вот это я еще понимаю

но в целом да, если проблемы не видно - не вижу смысла продолжать. Виднее ее не станет

то есть ты не видишь проблемы с кастылем что бы отработал __set?

Если я перепишу его на коллекцию, которая будет инкапсулировать __set, то эта претензия исчезнет?

Если я перепишу его на коллекцию, которая будет инкапсулировать __set, то эта претензия исчезнет?

ммм... возможно, не уверен сейчас.

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

словом, все что меня напрягает это кастыли, которые не явные. Коллекции сделают это явным кастылем и я как минимум буду спокоен)