Laravel по-русски

Русское сообщество разработки на PHP-фреймворке Laravel.

Ты не вошёл. Вход тут.

#1 23.06.2019 06:59:14

Why I don’t want to use Laravel anymore

medium.com: Moving away from magic — or: why I don’t want to use Laravel anymore

Любопытная статья. Не разделяю максимализм автора, но чтиво любопытное. На мой взгляд, Eloquent выжал из концепции ActiveRecord всё что можно, но этого неостаточно.


There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

Не в сети

#2 24.06.2019 19:25:27

Re: Why I don’t want to use Laravel anymore

Я на Laravel не писал уже много лет, так что о нем конкретно говорить не могу, но вообще, когда читаю статьи про фреймворки, ощущение, что народ 90% рабочего времени пишет модели, формы и классы (или печатает со скоростью 10 знаков в минуту), и поэтому кодогенераторы и магические dependency injection (и другие injection, вроде свойств в Eloquent) приносят такое невероятное облегчение и хайп. Особенно меня вымораживают кодо-комментарии (@dataSource и пр.) — ладно там в юнит-тестах, но в основном коде, это ж маразм, основывать логику на комментариях!

В моей работе как-то все наоборот. Да, есть модели (сильное название — класс со свойствами), но вообще не вижу никаких проблем от руки написать такой класс на каждую таблицу (даже если их 20-30 штук). Это делается даже «не приходя в сознание». И не ломаешь голову, откуда пришло то или иное свойство. Явное лучше скрытого. С методами аналогично — руки не отсохнут написать, что первый аргумент это User $user. На такие рутинные операции тратится может 5% времени. Остальные 95% — никакой фреймворк не облегчит, потому что это собственно и есть бизнес-логика, где требуется продумывание и планирование и только потом код.

А вот шаблонизаторы, если они легкие и прозрачные, сильно облегчают жизнь — писать HTML на голом PHP не продуктивно. ORM — если очень-очень легкая, то имеет место быть для всяких User::find(123), однако обязательно должен быть и прямой доступ к SQL (в виде подготовленных запросов), иначе придется переписывать пятиэтажные (JOIN) запросы с WHERE, HAVING, ORDER BY и LIMIT из человекочитаемого SQL в человеконечитаемые вызовы методов. ORM такие запросы эффективно сгенерировать вряд ли сможет, да и будешь уверен, что после очередного обновления и изменения внутренней логики ORM твой запрос не стал в 10 раз медленнее, потому что она его поняла как-то не так. Отлаживать удобнее, опять же.

Нужно смириться, что код писать придется так или иначе, и что «удобства» добавляют огромное число неконтролируемого тобой кода, который ни отладить (из-за объема и из-за магии), ни понять.

Вместо фреймворков, ИМХО, лучше тянуть (качественные) пакеты, потому что они не навязывают способ работы и воспринимаются как черный ящик — вызывай вот это вот так-то для получения такого-то результата и больше ни о чем не думай. Их можно воспринимать как стандартные функции PHP. Ирония в том, что пакеты как раз стараются писать без привязки к фреймворкам…

Не в сети

Подвал раздела