Валидация, логирования, очереди - это инфраструктурный код и лежит выше логики контроллера. Если человек пишет на фреймворке подразумевается что он им пользуется.
Речь же о бизнес логике в контроллере. Лучше бы конечно он код показал.
Вы воюете с ветряными мельницами. При чём здесь политики, мидлевари и 403? Вы вопрос читали?
Человек делает оформление заказа с разными способами оплаты. Нет у laravel решения подобного рода, есть Cashier но он для подписок и завязан на американский сервис.
Вот и говорю что карго-культ. Откуда вы берете про эти сервисы в ларавеле? Нет там никаких волшебных сервисов, которые делают плохой код хорошим. Сервисы ты должен сам головой придумывать на основании требований задачи. Не знаю лазили ли вы в код самого ларавел, но у Тейлора внутри портал в адский код, которому не помешали бы знания правил рефакоринга.
Поэтому я и дал ссылку на рефакторинг, где описывается проблема, причина, даются варианты решений и описываются их достоинства и недостатки.
Sanes, вы несете бред. Никаких фреймов там нет, innerHTML меняется элементрным присваиванием. Реактивный фреймворк это вовсе про другие цели, про изменения состояния стейта.
Глеб, ты главное держись и ни за что не читай документацию как советует JhaoDa.
Ты же понимаешь, что даже не демонстрируешь достаточно кода, чтобы понять в чём проблема. Какие две разные страницы, как ты выводишь это сообщение, какая цепочка мидлеварей у этого роута.
По поводу exit, смешной момент в том, что выше вы пишете return 'Платеж не найден'; Нигде в документации не пишут использовать exit для вывода, это останавливает работу всего фреймворка. Нужно делать return, а лучше использовтаь https://laravel.com/docs/9.x/responses
Такое чувство, что код писало 2 разных человека. Прочтите полностью. документацию перед работой. Это час-два занимает.
JhaoDa, ну какая документация. Он же реально платёжный запрос собрался делать без токена. Про DI не знает. Данные таскает не из реквеста, а из POST, значит и про тесты не слышал. Про update моделей не слышал. Что такое транзакции, зачем они нужны? Про логирование не догадывается. Про респонс так же. exit('200') думает небось что так заголовки посылаются.
Хорошо, если он для себя делает. А если на заказ, то на памятнике выгравируют - за то что документацию не читал.
dsmoke, гибкость - это про следствие принципам SOLID. Плюс надо учитывать нагрузку, количество данных, всякие UI фишки, зачастую даже переписка и уточнения задачи занимает больше времени чем программирование.
По умолчанию используется ленивая загрузка и данные подтягивают только при обращении. Если вы выбрали несколько записей, а затем начали обращаться к связанным полям, то каждый раз будут посылаться новые запросы.
Если используете with(), то у вас будет лишь два запроса - сама выборка и ОДИН отдельный, запрос который вытянет все связанные данные. Что гораздо лучше.
Слава, только у вас в примере подзапрос по where c2.id = c1.id
Я потому вас и пытаю. Видимо, у вас проблемы не только с кверибилдером ларавел, но и с sql в целом, тогда вам нужна ещё помощь.
tukbaevbr, смотря что тестируете. Если интеграционный тест - то не нужно. Если юнит - то не надо гонять базу, готовить миграции, фэктори и сиды для тестов. Это опять же к оценке качества кода через написание тестов. Простые тесты - значит код нормальный, его просто переиспользовать и саппортить.
Слава, мне казалось, что это задача вопрошающего максимально корректно донести свой вопрос. А то вы и на меня наехали, и выше отписались что withcount не то, но оказывается это то что нужно.
Делать подзапрос на себя же по id, выглядит крайне нелогично, не говоря уже о производительности.
tukbaevbr, если так не делать, то маленький проект превращается в большой и тродноподдерживаемый уже через месяц. Вот на примере простого теста уже вылезут косяки - тебе через костыль нужно замокать статический метод where, проверить что в аргументы приходят волшебная строка 'use' и 0, вернуть прокси объект с методом get. В итоге 4 костыля ради одной строчки кода.
И это лишь тесты, а в реальном проекте выльется в огромное дублирование кода, ошибки и трудности поддержки.
tukbaevbr, не используются инъекции зависимостей. Зато используются статические вызовы, магические строчки ('use'), магические цифры (0) и цепочка вызовов - ничего из этого в контроллерах быть не должно от этого не только архитектура выиграет, но и код станет проще.
public function armory_all(Armory $armory) {
return $armory->unused();
}
Речь же о бизнес логике в контроллере. Лучше бы конечно он код показал.