Я пишу небольшие проекты на laravel и как многие начинающие разработчики закидываю логику в контроллеры. Но маленьких проектах, которые нужно быстро сделать и сдать это не вызывает никаких проблем, но сейчас я сажусь за серьезный проект, который буду пилить пару месяцев и сделать его хочется хорошо.
Я много раз читал и слышал, что толстые контроллеры – это ужасно, это антипаттерн, но не могу уразуметь почему. Валидация мы вынесли в Request, Вся логика обращения в БД в модели или репозитории, что остается в контроллере? одна строчка возвращающая view? Тогда зачем контроллеру вообще существовать, закинуть эту строку в роуты и все. В чем проблема написать в контроллере пару where, join, мб как-то по хитрому обработать данные?
Ну и предположим, что я осознал, почему в контроллерах логики быть не должно. Тогда просто переносим все в модель? зачем плодить репозитории (кроме как абстрагироваться от конкретной ORM) и остальные сущности?
В чем проблема написать в контроллере пару where, join, мб как-то по хитрому обработать данные?
Завтра появится задача сделать всё то же самое, но в консоли. Потащищ копипасту или начнёшь выносить общий код в реквесты, репозитории и прочие места?
Тогда просто переносим все в модель? зачем плодить репозитории (кроме как абстрагироваться от конкретной ORM) и остальные сущности?
Репозитории актуальны с паттерном DM и не актуальны с паттерном AR.
При всём при этом следует помнить, что паттерны — не догмы. Паттеры для человека, а не человек для паттернов. Если у тебя одностраничник на хайповую тему, который надо сделать быстро и жить ему месяца два, то не парься и пиши всё в контроллерах. Выживет — перепишешь.
Sinus_314, толстые контроллеры - это не антипатерн, это ошибка при использовании MVC. Просто потому, что это рушит весь смысл MVC. И да, вы можете не использовать MVC, и когда пользовательские запросы приходят одинаково, обработка их одинакова, а вывод тоже всегда один и тот же, то проблем не будет.
Если строго следовать принципам SOLID, а именно SRP (принцип единственной ответственности), то задачей контроллера является презентовать какую-то часть приложения в виде HTTP endpoint (в частном случае REST).
Собственно логика не должна находиться в контроллере, потому что способы обращения к этой логике (через HTTP, Service Bus, Telegram, Discord, периодический вызов по крону и т.д.) ортогональны собственно бизнес-логике.
Но это становится действительно критично в сложных проектах. В типичных сайтах, когда не возникает такой задачи вызывать логику из разных мест - этот принцип часто нарушается без существенных последствий.
Простой
Средний
Простой
Простой
Простой
