В моей работе как-то все наоборот. Да, есть модели (сильное название — класс со свойствами), но вообще не вижу никаких проблем от руки написать такой класс на каждую таблицу (даже если их 20-30 штук). Это делается даже «не приходя в сознание». И не ломаешь голову, откуда пришло то или иное свойство. Явное лучше скрытого. С методами аналогично — руки не отсохнут написать, что первый аргумент это User $user. На такие рутинные операции тратится может 5% времени. Остальные 95% — никакой фреймворк не облегчит, потому что это собственно и есть бизнес-логика, где требуется продумывание и планирование и только потом код.
А вот шаблонизаторы, если они легкие и прозрачные, сильно облегчают жизнь — писать HTML на голом PHP не продуктивно. ORM — если очень-очень легкая, то имеет место быть для всяких User::find(123), однако обязательно должен быть и прямой доступ к SQL (в виде подготовленных запросов), иначе придется переписывать пятиэтажные (JOIN) запросы с WHERE, HAVING, ORDER BY и LIMIT из человекочитаемого SQL в человеконечитаемые вызовы методов. ORM такие запросы эффективно сгенерировать вряд ли сможет, да и будешь уверен, что после очередного обновления и изменения внутренней логики ORM твой запрос не стал в 10 раз медленнее, потому что она его поняла как-то не так. Отлаживать удобнее, опять же.
Нужно смириться, что код писать придется так или иначе, и что «удобства» добавляют огромное число неконтролируемого тобой кода, который ни отладить (из-за объема и из-за магии), ни понять.
Вместо фреймворков, ИМХО, лучше тянуть (качественные) пакеты, потому что они не навязывают способ работы и воспринимаются как черный ящик — вызывай вот это вот так-то для получения такого-то результата и больше ни о чем не думай. Их можно воспринимать как стандартные функции PHP. Ирония в том, что пакеты как раз стараются писать без привязки к фреймворкам…
]]>Любопытная статья. Не разделяю максимализм автора, но чтиво любопытное. На мой взгляд, Eloquent выжал из концепции ActiveRecord всё что можно, но этого неостаточно.
]]>