11. В классах-контроллерах не должно быть бизнес-логики, она должна быть в сервис-классах
Почему? Потому что SOLID.
Если нужно ещё доводов, то начните нарушать это правило и очень скоро заметите, что ваш проект постепенно превращается в нечто нелогичное, запутанное и малопонятное новым участникам команды.
Вообще, если говорить о SOLID, то польза от их соблюдения не всегда очевидна разработчику проекта. Он хорошо знает свой код, разбирается с кодом коллег на этом же проекте, участвует во всех командных обсуждениях проекта. Ему ВСЁ ПОНЯТНО, он - один из создателей проекта.
Части проекта (логика, требования, комментарии, тесты, скомпилированный код) живут в памяти такого разработчика. Разработчик сам является частью проекта. Ведь проект - это не только код, но и всё, что его окружает (команда, инфраструктура, документация и т.д.). В итоге мы получаем ситуацию, когда часть наблюдаемой системы (разработчик) наблюдает сама за собой.
Такой внутренний наблюдатель неизбежно знает о проекте намного больше, чем проект может рассказать о себе стороннему наблюдателю, не являющемуся частью проекта. Эти скрытые от посторонних знания дают разработчику ложное представление о том, что проект идеален и без SOLID (или любого другого общепринятого соглашения о разработке).
Есть ещё одна причина искажения мнения о проекте у разработчика, являющегося частью проекта. Оценивая проект, частью которого он является, разработчик как бы смотрит в зеркало и оценивает самого себя. Ну, кто из нас, стоя перед зеркалом, не считает себя пусть не идеальным, но точно молодцом? )
С момента появления искажения восприятия проекта оно начинает дружить с ленью разработчика. И дружить не просто так, а против SOLID:
- вот тут можно добавить в контроллер код для расширенной проверки прав доступа,
- а здесь можно сделать в контроллере преобразование структур данных,
- от направления из контроллера в базу данных запроса, точно никто не пострадает, ведь другой логики нет: просто достали из базы и отдали в ответ на запрос извне,
- зачем делать отдельный интерфейс для конфигурирования документации на API приложения? Если разместить такую конфигурацию в контроллере, то всё равно код останется ПОНЯТНЫМ.
В итоге мы получим не красивый и аккуратный код, который легко понять и протестировать, а большой комок грязи вперемежку со спагети, отыскать концы в котором - будет нетривиальной задачей.
Именно поэтому: никакой логики в классах-контроллерах, только маршрутизация запросов.
Продолжение следует...