Почему вы не должны использовать Laravel Перевод

Я был разработчиком более 20 лет и использовал множество фреймворков PHP, включая Laravel, Cake, Zend 1 и 2, CodeIgniter, Yii и самодельный, который я написал некоторое время назад.

Опыт дает вам перспективу, которую вы не получите, просто используя один фреймворк снова и снова. Как программисты, мы — существа привычки. Мы используем то, что знаем, и если мы использовали какой-либо язык или фреймворк в течение последних 5 лет, что ж, это наш любимый инструмент. Это знакомо, как старый друг, которого мы хорошо знаем.

Но то, что мы знакомы с языком или фреймворком и привыкли к ним, не означает, что они лучше всего подходят для тех проектов, которые мы создаем.

Я пришел из предприятия, проекты, которые включали сотни разработчиков, работающих над различными частями массивных интерактивных приложений. Действительно крутая вещь в работе с такой большой и разнообразной группой людей заключается в том, что вы учитесь тому, как делать то и это, не только более эффективно, но, что более важно, автономно и расширяемо.

Я не говорю, что Laravel — плохой фреймворк для самых разных проектов, но для очень опытных разработчиков Laravel не лучший выбор.

Почему? Давайте рассмотрим несколько причин…

Laravel — это не PHP

Я читал статьи молодых программистов, превозносящих достоинства Laravel и то, как легко им пользоваться. В одной части я прочитал, что кто-то сказал, что им даже не нужно изучать PHP и SQL, потому что Laravel позаботится об этом за вас!

На самом деле я сочувствовал этому чувству, потому что в молодые годы у меня были точно такие же мысли. Мне нравилось работать с ORM, потому что (я думал) мне не придется изучать SQL. Это распространенное заблуждение.

Дело в том, что Laravel СЛИШКОМ много держит за руку. По крайней мере, для более опытных программистов.

Я тоже графический дизайнер. Laravel гордится тем, что является фреймворком для «ремесленников». Такое впечатление, что Laravel — это фреймворк для людей, которые толком не умеют программировать и не хотят учиться. Я понимаю.

Однако в какой-то момент всем нам, «ремесленникам», нужно будет вырасти, чтобы стать настоящими программистами. Laravel — это не PHP как таковой, он использует «выразительный» синтаксис или то, что было придумано как «синтаксический сахар», чтобы скрыть от вас то, о чем, по его мнению, всем нам, «ремесленникам», не нужно беспокоиться.

И это нормально. Пока нам не нужно беспокоиться про это.

В какой-то момент Laravel сорвется, и вам придется замарать руки настоящим кодом, реальным внедрением зависимостей, настоящими фабриками, настоящим SQL и т.д.

И весь этот «выразительный» синтаксис имеет скрытую цену, которую вы не видите в данный момент — Laravel — чрезвычайно самоуверенный фреймворк.

Что означает мнение?

Такие фреймворки, как Laravel, CakePHP и другие, имеют очень специфические способы выполнения действий. И до тех пор, пока ваш вариант использования не выходит за рамки того, что вообразили разработчики Laravel, все в порядке.

Но именно тогда, когда ваш «прецедент» становится «пограничным случаем» Laravel, когда все становится интересным, и внезапно вам говорят использовать какой-то очень странный код, который углубит вас в внутренности Laravel, чтобы показать, что на самом деле происходит под капот.

Внезапно вы обременены кодом, с которым не знакомы. Это работает? Вероятно. Вы знаете, что вы только что сделали и почему? Возможно нет.

И в этом заключается проблема.

Не используйте ORM.

Просто научите себя SQL. Честно говоря, научиться писать хорошие запросы не так уж и сложно. ORM делает вас ленивым, и в конце концов вам все равно придется писать SQL.

Я использовал ORM на предприятии, и я ненавидел это. Доктрина хуже всего. Конфигурация проста для простых проектов, но когда вы усложняете сложные отношения с помощью вложенных сущностей и рекурсии, гидратации, вам захочется рвать на себе волосы.

Мне приходилось писать целые классы, посвященные только настройке Doctrine DQL (язык запросов Doctrine) для того, что должно было быть простым объединением SQL и разбиением на страницы. Это не просто, когда вы используете ORM.

Кроме того, ORM стоят дорого. Один запрос Doctrine для вложенных сущностей может привести к буквально десяткам запросов к вашей базе данных под капотом. Даже для самых простых сущностей мы видели от 6 до 8 запросов к БД, хотя должно было быть не более 1−2.

Нам, PHP-программистам, нравится выводить объекты на экран, чтобы посмотреть, что в них находится. Вы можете забыть об этом с ORM. С рекурсией выгрузка объекта на экран займет всю доступную память PHP, и вместо этого вы просто получите сообщение об ошибке.

https://medium.com