SB
В том то и цель чтобы меньше держать. У вас при функциональном кохижене когнитивная нагрузка меньше ибо изоляция выше
Size: a a a
2021 August 23
✨
ну вон уже Arky пошел все связи резать ))
SB
Так я по прежнему против связей. Но я и не говорю везде объекты и агрегаты пихать.
Просто связи зло. Сразу минус реплики. Минус целостность данных.
Просто связи зло. Сразу минус реплики. Минус целостность данных.
✨
ну как же, если мы храним id связи, это не означает что её нет
SB
Ещё раз я про объекты и связь между ними.
Когда один объект использует другой для принятия решений. Тоесть когда один имеет доступ к другому
Когда один объект использует другой для принятия решений. Тоесть когда один имеет доступ к другому
SB
Я вообще больше про GRASP.
Вполне понятная последовательна штука. Не знаю что вы против имеете. Я отсылал к видам кохижена. Даже не к каплингу(он же связи вроде как про которые я не писал но вы их увидели).
Вполне понятная последовательна штука. Не знаю что вы против имеете. Я отсылал к видам кохижена. Даже не к каплингу(он же связи вроде как про которые я не писал но вы их увидели).
✨
я наверное имею против тогда, когда это переходит какой-то здравый смысл
✨
я прекрасно понимаю о чем вы говорите, и также придерживаюсь этой стратегии, но не параноидально везде и во всем
✨
каогда речь шла о том, как хранить id в сущности, со связью или отдельной связанной сущностью - wtf...
✨
из этого и следует вывод, что ваш путь всезде и всегда
SB
Окей как определить когда и где граница?
Просто 90% программистов не слышали про кохижн. И 99% лепят случайный или логический но не функцональный. Я уж молчу что используют классы но пишут процедурно исключительно.
Просто 90% программистов не слышали про кохижн. И 99% лепят случайный или логический но не функцональный. Я уж молчу что используют классы но пишут процедурно исключительно.
проиллюстрируйте примером пожалуйста
SB
Так это же идеальный показатель проблем в дизайне. И именно проблема с консистентностью данных. Я вот не разу не видел чтобы при таких связях кто то лочил все связанные записи. А значит решение принимается на устаревших потенциально данных и приводит к повреждениям данных.
Я вот и не понимаю зачем своими руками себе данные ломать.
Я вот и не понимаю зачем своими руками себе данные ломать.
✨
а тут не нужно их искать, она сама к тебе либо придет, либо из анализа бизнеса
✨
не совсем понимаю, каким образом мы ломаем себе данные? При работе с доктриной все связанные объекты автоматом в транзакции
мне для понимания не хватает примера
✨
вот тоже одна из прелестей доктрины работая с объектом
можно реальеый кейс на примере с 3-4 сущностями, с двумя вариантами : как не правильно - и почему, как правильно и какие это проблемы решило
SB
Например заказ. И связан с айтемами. Мы считаем общию цену и по ней принимаем решение.
Но в между тем когда мы прочитали цену и приняли решение цена изменилась. Тоесть мы приняли неверное решение. Или количество товара изменилось.
Но в между тем когда мы прочитали цену и приняли решение цена изменилась. Тоесть мы приняли неверное решение. Или количество товара изменилось.
SB
Транзакция обеспечивает всё или ничего. Она не гарантирует что данные которые были в транзакции не менялись. Плюс транзакция не влияет на то что вы ПРОЧИТАЛИ и использовали для записи.
А то что вы ПРОЧИТАЛИ может уже быть другим сразу после чтения и перед тем как вы записали реакцию на изменившиеся данные
А то что вы ПРОЧИТАЛИ может уже быть другим сразу после чтения и перед тем как вы записали реакцию на изменившиеся данные