AH
Здесь видна бизнес-логика, смешанная в одном методе. Я бы ее разбил на несколько, где каждый выполняет свою чётко поставленную задачу.
Size: a a a
2020 May 13
И
Здесь видна бизнес-логика, смешанная в одном методе. Я бы ее разбил на несколько, где каждый выполняет свою чётко поставленную задачу.
суть не в этом. Класс с кучей методов или Класс с одним методом для одного конкретного действия?
A
тут еще транзакции нет... видимо её должно обеспечивать что-то снаружи. но там возникнут и другие проблемы.
И
тут еще транзакции нет... видимо её должно обеспечивать что-то снаружи. но там возникнут и другие проблемы.
какие
A
базы данных
И
я думаю, что транзакция в контроллере будет, как самый верхний слой
A
ну хорошо. тогда возникнет куча проблем. начиная с того, что каждый кто вызывает этот класс должен обеспечить транзакцию.
A
кроме того, там наверняка должны быть и другие вещи, например... да банально послать письмо этому юзеру.
A
делать это в транзакции - не айс.
AH
Я вот тут
echo увидел. Как представил что это в Лару пишут, так сердце ёкнуло.DE
Модель Laravel предоставляет все необходимые методы для работы с базой данных. Каждая модель отвечает за свой участок кода. Смешивать их - плохо. В Вашем коде, например, есть открепление записи фаворита, то есть действие над одной моделью из другой. Во-первых, это бизнес-логика, что-то к кому-то цеплять. Во-вторых, это неочевидное поведение, т.к. общение происходит в нелогичном для этого месте.
Если Вы так кичитесь своими знаниями ООП, дак выкиньте этот Laravel - это ж чемодан антипаттернов. На кой от Вам вообще нужен? Пишите свой код. Будет всё по канону... Вашему.
Начинаешь надоедать со своей инкапсуляцией. Мне по-барабану что и как называется. Я вижу принцип толстой модели, объединяющей в себе как работу с данными, так и бизнес-логику, включая работу с не родными данными из других моделей. Это плохо.
Если следовать Вашим принципам, то на фига вообще нужны контроллеры, сервисы, валидаторы?... Суйте всё в модели! Это ж инкапсуляция! Не отказывайтесь от своих принципов.
Если Вы так кичитесь своими знаниями ООП, дак выкиньте этот Laravel - это ж чемодан антипаттернов. На кой от Вам вообще нужен? Пишите свой код. Будет всё по канону... Вашему.
Начинаешь надоедать со своей инкапсуляцией. Мне по-барабану что и как называется. Я вижу принцип толстой модели, объединяющей в себе как работу с данными, так и бизнес-логику, включая работу с не родными данными из других моделей. Это плохо.
Если следовать Вашим принципам, то на фига вообще нужны контроллеры, сервисы, валидаторы?... Суйте всё в модели! Это ж инкапсуляция! Не отказывайтесь от своих принципов.
Привёл ссылки, по которым всё уже рассказал.
ИЛ
Да там скорее общий пример, фреймворко-независимый
AH
Да там скорее общий пример, фреймворко-независимый
Предполагаю что это так, иначе бы не было смысла. Но испуг не откатить)
ИЛ
Предполагаю что это так, иначе бы не было смысла. Но испуг не откатить)
)
DE
Ну как-бы смотреть надо со включенным звуком и сначала, а не просто слайды листать справа налево.
И
кроме того, там наверняка должны быть и другие вещи, например... да банально послать письмо этому юзеру.
тогда что делать? завернуть в транзацию прямо в методе, а письмо отправить рядышком? (или выкинуть эвент)
RK
вот переписать ради прикола в то в как я это вижу например?
И
Да это просто пример
A
тогда что делать? завернуть в транзацию прямо в методе, а письмо отправить рядышком? (или выкинуть эвент)
в итоге мы начинаем понимать, что такой класс делает две вещи ) логику.. и еще с базой данных работу. и ещё кое-чего.
DE
Если заменить на {{ ... }} или <?= ... ?> то будет лучше?