Типичные ошибки при работе с Laravel
Выбирая framework для нового проекта, всегда важно помнить, что framework – это инструмент, а не цель. Неправильно выбранный инструмент может привести к сложностям при развитии проекта. Правильно выбранный, но неправильно используемый инструмент может привести к ещё большим сложностям.
Нарушение принципа единственной ответственности (SRP)
Доступные в интернете примеры решения задач с использованием Laravel на каждом шагу нарушают принцип единственной ответственности. Скорее всего, это связано с низким порогом входа и активной популяризацией Laravel как простого в освоении фреймворка. Также свой вклад вносит то, что ORM Eloquent использует ActiveRecord, который сам по себе нарушает этот принцип. Изначально заложенная хорошая архитектура многократно окупится при дальнейшем рефакторинге, поэтому не следует нарушать SRP в угоду «простоте» кода.
Чрезмерная надежда на «магию» фреймворка
На этапе освоения Laravel я столкнулся с проблемой, связанной с инъекцией сущностей в методы контроллера. В приложении было несколько маршрутов, в которых было два параметра, например:
/api/v1/user/{user_id}/organization/{organization_id}
В методе контроллера параметры были с теми же именами и в том же порядке. Спустя примерно полгода, фронт-разработчики почему-то решили, что логичнее было бы поменять местами organization и user в маршруте. В полной уверенности, что Laravel всё сам определит и подставит так, как нужно, я сделал изменения в маршруте, не трогая метод контроллера. Думаю, не нужно объяснять, что последствия были довольно плачевными.
Злоупотребление использованием фасадов
Laravel содержит большое количество фасадов со статическими методами, которые доступны в любом классе. Злоупотребление их использованием приводит к тому, что архитектура приложения теряет стройность. Особенно активно используется фасад DB, позволяющий получить прямой доступ к данным из базы, минуя ORM. Здесь важно понимать, что если у вас возникает необходимость использования фасада DB, например, в контроллере, то с архитектурой уже что-то не так. В идеале использование фасадов необходимо локализовывать в отдельных классах/иерархиях классов, а уже эти классы внедрять туда, где есть необходимость в их использовании.
Злоупотребление использованием IoC-контейнера
В Laravel IoC-контейнер доступен в любом месте кода с использованием хелпера app. В результате очень часто вместо честного внедрения зависимостей используется разрешение интерфейсов через контейнер. Это приводит к тому, что код становится сильно зацепленным и рефакторинг усложняется многократно, потому что зависимости не видны явно. Когда у вас возникает желание использовать app, нужно ещё раз хорошо подумать, нельзя ли использовать в этом случае явное внедрение зависимостей.
На этом предлагаю завершить краткий обзор типичных ошибок при работе с Laravel. Пишите качественный код!
