Size: a a a

2021 December 27

D

Dmitry in symfony
благодарю за мнение
источник

D

Dmitry in symfony
был бы благодарен за дополнительные мнения, кто как организовывает такие вещи
источник

SP

Sergey Protko in symfony
Ответ зависит от разницы между разными сущностями и "для email или для зарегистрированного". Возможно общую часть логики можно отделить от ресипиента.

Если логика одинаковая то первый вариант. Если нет - надо разбираться где отличия

Словом мало инфы
источник

D

Dmitry in symfony
разница в привязке к пользователю  по ид
если для зареганного то потом возьмем его мыло по ид пользователя
если для незареганного, то сразу впишем мыло
и вписывать сразу мыло зареганного нельзя, его можно сменить у зареганного пользователя, а я не хочу еще и синхронизировать мыло у пользователя и в напоминалке
источник

D

Dmitry in symfony
я думал сделать нечто вроде
ReminderEntitySource -> oneToOne ReminderRecepient
но по сути это выходит тот же вариант 1
источник

ND

Nikolay Deriglazov in symfony
Если это исключительно уведомления на email, то пусть будет только email. А уже фабрика по созданию этого уведомления пускай заботится о том, где это email брать
источник

D

Dmitry in symfony
проблема в том что если использовать фабрику которая где-то этот имейл возьмет, то мы получим слепок на момент создания, а мне этого не нужно
пользователь может сменить мыло в любой момент и мне нужно отреагировать
как я уже сказал, синхронизировать мыла не хотелось бы
источник

D

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

D

Dmitry in symfony
+ у меня еще есть 2 способа оповещения для зареганных, так что чисто вписывать мыло не вариант вообще
источник

SB

Sergei Baikin in symfony
1 можно менять мыло в уведомлениях после того как пользователь сменил свое и того разницы не будет

2 Или не вижу смысла в чем разница между зареганым и не зареганым пользоватлем там и там можно создать пользоватля и его мыло. То что пользователь зареган к айди пользовтеля и его емейла имеет совершенно опосредованое отношение. В таком разе тоже разницы нет и можно связывать по айди
источник

D

Dmitry in symfony
у зареганных есть еще как минимум 2 способа оповещения, их можно не только по мылу оповестить
источник

SB

Sergei Baikin in symfony
И как это мешает зареганых и не зареганных оповещать по мылу одинаково
почему уведломлениям не пофиг на то что зареган он или нет?
источник

D

Dmitry in symfony
так оповещать по мылу их можно одинаково
я ж и пытаюсь понять как сделать лучше и что выбрать из приведенных вариантов

незареганного только по мылу можно оповестить с этого ремайндера
зареганного по мылу + еще 2 канала связи
источник

D

Dmitry in symfony
вот я и думаю как бы лучше организовать сущности
источник

SB

Sergei Baikin in symfony
Так зачем тут упоминать вообще зареган он или нет
У вас есть пользователи у них каналы связи
все
Факт регистрации не меняет ничего в вашем уравнении
источник

ND

Nikolay Deriglazov in symfony
Так у тебя логика зависит от реципиента получается
источник

ND

Nikolay Deriglazov in symfony
@fes0r правильно написал.
источник

D

Dmitry in symfony
потому что я не хочу перегружать ремайдер синхронизацией с пользователем
источник

D

Dmitry in symfony
лишняя точка отказа мне не к чему, пока что..
источник

SB

Sergei Baikin in symfony
Протекание связи и знания о регистрациях намного хуже
И где там синзронизация?
Хотите синхронные запросы по айди делайте по айди
просто каждый пользовтель будет иметь свои канылы
и пофиг ремайндеру почему  у одного один канал а у другого 3 канала
ему какая разница ему важны каналы и только каналы
источник