Я очень люблю фреймворк laravel, пользуюсь им начиная с 3-й версии, тогда он был как глоток свежего воздуха на фоне zend и symfony. Уважаю Тейлора за проделанную работу, за принесённую в php фреймворки идею удобного апи и умение копировать лучшее из других фреймворков вроде RoR. О плюсах сказано уже много, но у него есть свои недостатки.

Эти недостатки не фатальны, а некоторые и вовсе мои личные привычки, которые другим покажутся надуманными. Всё дерьмо вылитое ниже не сильно влияет на мою оценку laravel, который считаю лучшим фреймворком в мире PHP. И спасибо @kotchuprik и его статье, который подтолкнул высказаться и дал некоторые идеи.

Фасады и статика, они везде, даже в начале  проекта у вас уже в routes.php есть Route::get и это при наличии хорошего DI, который позволяет отказаться от этого и получить нормальный автокомплит в IDE. А так приходится ставить IDE Helper. Почему-то комментаторы набросились на этот пункт, начали меня оскорблять и учить, но недобитый фасад из коробки есть, я не виноват.

Непоследовательность. Фреймворк очень долго переходил на PSR, но так до конца не перешёл. В папке database творится полный бардак. В app прямо в корне лежит моделька User. Роуты валяются в файлике app/Http/routes.php. Шаблоны расположены в директории resources, в отрыве от остального app. Предпочитаю когда есть директория с модулем, а уже в ней контроллеры, модели, шаблоны и т.д. А так получается каша, где все контроллеры свалены в кучу, с которой сложно работать на большом проекте. Сразу начинаешь оформлять код как пакеты, но появляется неудобство с прописыванием дополнительных путей для консольных команд.

Консольные команды и контроллеры почему-то разные сущности, при этом контроллеры вовсе отправлены в папку Http с роутингом и мидлеварами. Всегда считал что консоль должна работать так же как и при запросе из браузера и делал синтаксис.

console news/1
console user/1/store --method=post --data="name:Petja, login:God"

Отсутствие базовых классов для Model, как это есть для контроллеров, запроса, событий. А вот модельки при генерации наследуются от модели из вендора, что создаёт трудности с расширением, приходится править цепочку наследования после кодогенерации.

Версионирование. Между версиями большие изменения, при этом в минорных релизах умудраются убивать обратную совместимость, например, убрав метод list из моделей между 5.2 и 5.3, а не подождав до 6-й и там отрубив deprecated. Хотя сейчас есть LTS версия, но на ней мы уже ловили баг с роутингом, правда виной тому был вендорский пакет от symfony.

Есть древний принцип версионирования http://semver.org/lang/ru/, согласно ему минорная версия лишь добавляет функционал не ломая обратной совместимости.

Миграции. Они до сих пор не по psr и без немспейсов, название класса не совпадает с именем файла из-за чего возникают коллизии. Например, у вас был раздел новости и таблица под него с миграцией

php artisan make:migration create_news_table --table=news

Создаст файл 2014_01_01_000000_create_users_table.php с классом CreateNewsTable, затем этот раздел убрали, а церез год вернули, но он уже работает по другим правилам и содержит другие поля

php artisan make:migration create_news_table --table=news

2015_03_06_000000_create_users_table.php с тем же классом CreateNewsTable.

Отладка. Из коробки отсутствует дебаг панель, её нужно устанавливать отдельно. Не очень хорошо подменён error_handler, из-за чего в дев режиме иногда видишь белую страницу и нужно лезть в логи, чтобы узнать что права на папку не прописал. В том же дев режиме почему-то не логируются запросы к БД, из нужно руками включать через те же фасады \DB::enableQueryLog();

Elixir — не понимаю зачем Тейлор всунул из коробки эту нодовскую приблуду. Можно было прикрутить assetic или его аналоги, а там уже пусть разработчик через конфиги решает собирать ему всякие less c помощью php или node-ruby утилит. Assetic справляется с этими задачами, а проектах с большим количеством фронтенда всё равно пользуются webpack и grunt.

Формы. Почему-то выбросили компонент для работы с формами, теперь приходится пользоваться LaravelCollective, который является сторонним компонентом, а сам фреймворк не поддерживает функционал необходимый в каждом веб приложении. Для REST формы не нужны, но как раз ради этого кейса Тейлор создал отдельный фреймворк Lumen. А так laravel проигрывает на фоне других фреймворков не имея решения для форм из коробки.

Eloquent работает со связанными таблицами не через джойны, а с помощью IN, это весьма неудобно если например нужно отсортировать данные по связанной таблице — новости по колличеству комментариев.

Так же есть магические файндеры вроде where<field>(<value>) whereUsername(‘AmdY’), это очередной способ отстрелить себе ногу.

Модель это мусорка в которое объеденились:

  1. Непосредственно сама модель и её методы, мутаторы
  2. Коллекции для работы с набором моделей, итерирование, сортировка, фильтрация и т.д.
  3. Построитель запросов select, where, take, get, all
  4. Пагинатор paginate, append
  5. Скоупы
  6. Менеджер подключений setConnection, onWriteConnection …
    Многие методы и атрибуты статические сообветсвенно распостраняются на все объекты класса.
  7. Связи hasOne, hasMany ….
  8. Observer и методы creating, created,deleting и т.д. При этом эти методы так же статические и задевают все модели
  9. Работа с event-ами
  10. Сериализация, при этом только json, стратегии нельзя задавать

Скоупы, не понимаю зачем они нужны, они ломают автокомплит, вешаются на весь класс, а есть ещё глобальные скоупы.

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

Blade. Непонятные вещи творятся с шаблонизатором, выбран очень странный путь его развитие с внедрением опасных конструкций  @inject и @php, следующим шагом будет @eval и @goto? При этом нет удобных средств для контроля цикла foreach, чтобы узнать первая-последняя итерация или её номер. Делать такое приходится через вставку php кода <?php $i++; ?>. Ну и отсутствие режима песочницы, из-за возможности использования php тегов а так же @php, @inject наши шаблоны опасны и нельзя делать безопасные шаблоны-темы, так как они подвержены php injection.

Установка пакетов. В laravel 3 бандлы можно было устанавливать из командной строки, сейчас же вам нужно:

  1. Зайти на документацию по пакету
  2. Добавить пакет через composer
  3. Прописать его в providers
  4. Добавить alias для фасадов. Так лучше не делать, но иногда фасады это единственный способ переопределять статик ад в пакетах.
  5. Импортнуть конфиги-вьюхи, миграции, сиды и т.д.

Для 4-ки была идея специального установщика, но видимо она так и не попала в пятую.

Роутинг.  Нужно прописывать все роуты вручную, исключения составляют ресурсы. Раньше был метод controller (в 5.2 deprecated, в master уже нет), который автоматически делал роуты для целого класса, но его убрали. Кроме того невозможно задать схему /module/controller/action, приходится делать специальный роут {module}/{controller?}/{action?} который всё это перехватывает и вручную инициализиуется контроллер и дёргается метод.

Тесты. Если у вас установлен глобально phpunit, то без бубна тесты им не запустятся. Очень бесило то, что не работали обсерверы в моделях при тестировании, сейчас это починили. Ну и не нравится очередной велосипед вместо проверенного Codeception.

Документация, в ней очень много примеров плохого кода, использование фасадов, отсутствие DI, замыкания для роутов. Учиться хорошему стилю новички должны на laracast, где часть уроков платная.

Поддержка. В один прекрасный день Тейлор взял у убил все issue на github, такое отношения к багам пугает. LTS появилось очень поздно, лишь на версии 5.1. Ну и развитие идёт по пути того, что надо авторам для их проекта, а не под нужды сообщества.

Джуниоры. Свой кажущейся простотой фреймворк привлекает кучу новичков, которые не могут освоить даже документацию к фреймворку, composer, разобраться с автозагрузчиком и научиться устанавливать document root. Вот типичный пример таких джуниоров, которые даже синтаксиса языка не знают.

p.s. Подбрасывайте ещё недостатки, буду добавлять их в статью чтобы собрать в одном месте, а не ныть постоянно по мелочам.



1 Комментарии

добавить
Сергей
06.01.2017 20:37:58
Работаю с Laravel в данный момент и не понимаю почему на него все так дро**т?! Вполне себе юзабельный, но слишком уж тяжелый. А стек вызовов так вообще жуть.
Чтобы комментировать, нужно авторизоваться

Советуем почитать


Федеральная система
Сергей 0

Федеральная система "Город" читать далее

В прошлый раз описал процесс работы с платёжной системой Cyberplat, теперь хочу поделиться опытом работы с ФСГ (Федеральная система город).

Разработано сие чудо ЦФТ. Старались делать все по ГОСТ, поэтому произвести интеграцию не так просто, как хотелось бы (рассматриваем PHP).

0 11.07.2016 17:40:15

PHP Управление строками
Максим 0

PHP Управление строками читать далее

Мало кто из разработчиков задумывается о том, как устроено ядро PHP и что происходит «под капотом». Действительно, на практике большинству редко бывают нужны подобные знания, тем не менее обладать ими будет полезно. Статья рассказывает о том, как устроены строки в PHP и о различиях работы с ними в PHP 5 и 7.


Это мой первый перевод подобной статьи, тем более технически не самой простой. Обо всех неточностях пишите в комментариях или лично мне.

0 04.05.2016 23:28:31