0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: ioc-контейнер, laravel, фреймворк, программирование на php, ошибки, srp, php-фреймворк, framework</p>
1
<p>Теги: ioc-контейнер, laravel, фреймворк, программирование на php, ошибки, srp, php-фреймворк, framework</p>
2
<p>Выбирая<strong>framework</strong>для нового проекта, всегда важно помнить, что framework - это инструмент, а не цель. Неправильно выбранный инструмент может привести к сложностям при развитии проекта. Правильно выбранный, но неправильно используемый инструмент может привести к ещё большим сложностям. Как и любой другой framework,<strong>Laravel</strong>позволяет множеством способов "выстрелить себе в ногу". Рассмотрим<strong>наиболее типичные ошибки</strong>, совершаемые теми, кто начинает работать с Laravel.</p>
2
<p>Выбирая<strong>framework</strong>для нового проекта, всегда важно помнить, что framework - это инструмент, а не цель. Неправильно выбранный инструмент может привести к сложностям при развитии проекта. Правильно выбранный, но неправильно используемый инструмент может привести к ещё большим сложностям. Как и любой другой framework,<strong>Laravel</strong>позволяет множеством способов "выстрелить себе в ногу". Рассмотрим<strong>наиболее типичные ошибки</strong>, совершаемые теми, кто начинает работать с Laravel.</p>
3
<h2>Нарушение принципа единственной ответственности (SRP)</h2>
3
<h2>Нарушение принципа единственной ответственности (SRP)</h2>
4
<p>Доступные в интернете примеры решения задач с использованием Laravel на каждом шагу<strong>нарушают принцип единственной ответственности</strong>. Скорее всего, это связано с низким порогом входа и активной популяризацией Laravel как простого в освоении фреймворка. Также свой вклад вносит то, что ORM Eloquent использует<strong>ActiveRecord</strong>, который сам по себе нарушает этот принцип. Изначально заложенная хорошая архитектура многократно окупится при дальнейшем рефакторинге, поэтому не следует нарушать SRP в угоду "простоте" кода.</p>
4
<p>Доступные в интернете примеры решения задач с использованием Laravel на каждом шагу<strong>нарушают принцип единственной ответственности</strong>. Скорее всего, это связано с низким порогом входа и активной популяризацией Laravel как простого в освоении фреймворка. Также свой вклад вносит то, что ORM Eloquent использует<strong>ActiveRecord</strong>, который сам по себе нарушает этот принцип. Изначально заложенная хорошая архитектура многократно окупится при дальнейшем рефакторинге, поэтому не следует нарушать SRP в угоду "простоте" кода.</p>
5
<h2>Чрезмерная надежда на "магию" фреймворка</h2>
5
<h2>Чрезмерная надежда на "магию" фреймворка</h2>
6
<p>На этапе освоения Laravel я столкнулся с проблемой, связанной с<strong>инъекцией сущностей в методы контроллера</strong>. В приложении было несколько маршрутов, в которых было два параметра, например:</p>
6
<p>На этапе освоения Laravel я столкнулся с проблемой, связанной с<strong>инъекцией сущностей в методы контроллера</strong>. В приложении было несколько маршрутов, в которых было два параметра, например:</p>
7
/api/v1/user/{user_id}/organization/{organization_id}<p>В методе контроллера параметры были с теми же именами и в том же порядке. Спустя примерно полгода, фронт-разработчики почему-то решили, что логичнее было бы поменять местами<strong>organization</strong>и<strong>user</strong>в маршруте. В полной уверенности, что Laravel всё сам определит и подставит так, как нужно, я сделал изменения в маршруте, не трогая метод контроллера. Думаю, не нужно объяснять, что последствия были довольно плачевными.</p>
7
/api/v1/user/{user_id}/organization/{organization_id}<p>В методе контроллера параметры были с теми же именами и в том же порядке. Спустя примерно полгода, фронт-разработчики почему-то решили, что логичнее было бы поменять местами<strong>organization</strong>и<strong>user</strong>в маршруте. В полной уверенности, что Laravel всё сам определит и подставит так, как нужно, я сделал изменения в маршруте, не трогая метод контроллера. Думаю, не нужно объяснять, что последствия были довольно плачевными.</p>
8
<h2>Злоупотребление использованием фасадов</h2>
8
<h2>Злоупотребление использованием фасадов</h2>
9
<p>Laravel содержит большое количество фасадов со статическими методами, которые доступны в любом классе. Злоупотребление их использованием приводит к тому, что<strong>архитектура приложения теряет стройность</strong>. Особенно активно используется фасад<strong>DB</strong>, позволяющий получить прямой доступ к данным из базы, минуя<strong>ORM</strong>. Здесь важно понимать, что если у вас возникает необходимость использования фасада DB, например, в контроллере, то с архитектурой уже что-то не так. В идеале использование фасадов необходимо локализовывать в отдельных классах/иерархиях классов, а уже эти классы внедрять туда, где есть необходимость в их использовании.</p>
9
<p>Laravel содержит большое количество фасадов со статическими методами, которые доступны в любом классе. Злоупотребление их использованием приводит к тому, что<strong>архитектура приложения теряет стройность</strong>. Особенно активно используется фасад<strong>DB</strong>, позволяющий получить прямой доступ к данным из базы, минуя<strong>ORM</strong>. Здесь важно понимать, что если у вас возникает необходимость использования фасада DB, например, в контроллере, то с архитектурой уже что-то не так. В идеале использование фасадов необходимо локализовывать в отдельных классах/иерархиях классов, а уже эти классы внедрять туда, где есть необходимость в их использовании.</p>
10
<h2>Злоупотребление использованием IoC-контейнера</h2>
10
<h2>Злоупотребление использованием IoC-контейнера</h2>
11
<p>В Laravel<strong>IoC-контейнер</strong>доступен в любом месте кода с использованием хелпера<strong>app</strong>. В результате очень часто вместо честного внедрения зависимостей используется разрешение интерфейсов через контейнер. Это приводит к тому, что код становится сильно зацепленным и<strong>рефакторинг усложняется многократно</strong>, потому что зависимости не видны явно. Когда у вас возникает желание использовать app, нужно ещё раз хорошо подумать, нельзя ли использовать в этом случае явное внедрение зависимостей.</p>
11
<p>В Laravel<strong>IoC-контейнер</strong>доступен в любом месте кода с использованием хелпера<strong>app</strong>. В результате очень часто вместо честного внедрения зависимостей используется разрешение интерфейсов через контейнер. Это приводит к тому, что код становится сильно зацепленным и<strong>рефакторинг усложняется многократно</strong>, потому что зависимости не видны явно. Когда у вас возникает желание использовать app, нужно ещё раз хорошо подумать, нельзя ли использовать в этом случае явное внедрение зависимостей.</p>
12
<p><em>На этом предлагаю завершить краткий обзор типичных ошибок при работе с Laravel. Пишите качественный код!</em></p>
12
<p><em>На этом предлагаю завершить краткий обзор типичных ошибок при работе с Laravel. Пишите качественный код!</em></p>
13
13