В одном моём приложении стало слишком много посредников, но в каждом из них происходит по сути одно и то-же, обрабатывается переменная $request. Ещё так получилось что в каждом из них для каких-то проверок вызываются разные модели, но логика везде одна и та-же. Я не очень пока представляю магию ларавеля в плане оптимизации зависимостей по этому и вопрос: С точки зрения производительности в данном случае в плане использования памяти, лучше иметь по посреднику для каждой модели, или можно сделать один посредник где будут объявлены все модели, или лучше сделать один посредник и не использовать в нём модели а использовать только QueryBuilder? Или же это всё миллиметрика в плане ресурсов и важнее придерживаться принципов solid и наплодить кучу посредников для каждой модели и во все эти посредники внедрить зависимость для обработки схожей логики?
Я более чем уверен что мой вопрос глупый, но меня реально напрягает куча зависимостей, наследовний и т.д. хочется взять и навалить кода в один файл! И кажется что всем от этого будет лучше...
Логика в каждом посреднике практически одинакова, просто самого кода этой логики довольно мало, везде используются разные модели и случаются некоторые нестандартные ситуации, всё это можно засунуть в один посредник и все схожие логики сварить в одну, а для обработки тех нестандартных ситуаций сдобрить её некоторым количеством булевских конструкций.
Я думаю тут наверное всё дело уже в психологии, все на столько помешались на принципах solid, что перестали видеть чувство меры. А Laravel настолько SOLID, что для того что-бы взять и навалить всё в один скрипт, нужно заручится психологической поддержкой на тостере))))
Александр Аблизин: солид не зря придумали. Если кода много, то нельзя исключить вариант, когда для каких-то отдельных посредников надо будет вводить маленькие отличия. И что тогда, ифы плодить в общем коде? Плавали, знаем, ни к чему хорошему не приводит :)
Александр Аблизин не очень понятно что вы имеете ввиду под посредником, если это паттерн медиатор, то он как должен решать проблему кучи объектов, а не пораждать её как в вашем вопросе.
Вы написали, что у вас куча объектов которые принимают реквест, в ларавеле для подобного кейса уже есть middleware. Возможно вы пытаетесь решить не ту проблему и не с той стороны. Но слишком мало информации чтобы что-то советовать, распишите вопрос подробнее, с примерами кода
Вячеслав Плиско: под словом посредник, я и имел ввиду middleware т.е. удобный инструмент для быстрой работы с запросами без внедрения зависимостей в контроллер
Мой собственный ответ возник стихийно как продукт общения с коллегами (спасибо @kliss) и медитации. Нет каких-то лайфхаков на тему как сделать плохо. Плохо всегда можно сделать хорошо. Сейчас я сэкономлю полчаса на том что вынесу всю логику в один middleware создав разветвлённую сеть "if else" и погребу мою лень в одном файле. Но когда придёт время возвращать "технический долг" в момент масштабирования, я однозначно вспомню те 1.5 попугая которые я пожалел на выделение памяти (хотя я так и не знаю, жрут ли безнаказанно память невостребованные объявления моделей в Laravel, как он там потом всё маппит и оптимизирует для роута для меня пока магия). И это будет скорее всего во первых внезапно, во вторых несвоевременно. И это касается вообще всего что связано с архитектурой логики. Вычислительные мощности с каждым днём дешевеют, а вот нервная система пока нет.
Средний
Средний
