А нужны ли фреймворки в php если он сам фреймворк?

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

Это одна из религиозных мантр секты фреймворкистов.

На самом деле, обычно нет. Просто то же самое делается тем же количеством кода, но по-другому. Иногда вместо кода на java/php/whatever пишется конфиг фреймворка на xml/json/whatever еще большего размера, чем сам код, но этот конфиг почему-то за код не считают, его как бы нет. Или размазывают конфиг аннотациями по всему коду вообще. Или фреймворк даже умеет что-то делать по дефолту без конфига, и hello world и правда оказывается короче. Но быстро выясняется, что дефолтное поведение не подходит. И снова пишутся тонны конфигов и/или костылей.

Но это только начало. Потом в любом более-менее крупном проекте во фреймворке находится баг или отсутсвие какой-нибудь маленькой, но очень нужной именно для этого проекта, фичи. Тогда начинаются танцы с бубнами, написание воркэраундов и оберток, и все становится грустно.

Я уже не говорю о том, что фреймворки навязывают свою архитектуру (существует мнение, что именно этим «фреймворк» отличается от «библиотеки»), которая далеко не всегда оказывается подходящей для проекта. Но хиппи не думают об архитектуре, когда решают использовать фреймворк. Так что выясняется это обычно где-то в середине разработки, когда что-то менять уже поздно. И снова начинается обмазывание фреймворка костылями, чтобы вырваться из его ограничений.

Ага, давай ты вкратце покажешь как ты будешь делать роутинг без фреймворка.

Ну вот и я не осилил =) Во фреймворке, в некоторых, есть готовый роутинг, под который пишешь свои методы.

А без фреймворка будто бы архитектура приложения не превратится в нагромождение кода и всё будет кристально ясно.

Не в моем случае, я даже не программист, а просто любитель. Наврядли дело дойдет до angularJS :)

нельзя писать простой поддерживаемый и безопасный код руками.

Еще одна мантра фреймворкистов.

А фреймворки тоже на фреймворках пишутся, или все-таки руками? И если руками, то как фреймворки получаются простыми поддерживаемыми и безопасными? А если не простыми и не поддерживаемыми, то зачем они нужны?

Без фреймворка можно отрефакторить, потому что ничего не навязывает архитектуру. А с фреймворком, чтобы нормально отрефакторить, придется выкинуть фреймворк и переписать половину кода. Или написать слой костылей поверх фреймворка, который будет вечным источником неизбежного счастья для всей команды.

Я не имею ввиду тот случай, когда команда состоит исключительно из говнокодеров, которые в невнятное нагромождение кода умудряются превратить даже сочинение по литературе.

Почитай на досуге: https://8thlight.com/blog/uncle-bob/2015/08/06/let-the-magic-die.html

Для Ъ:

(...поскипано много текста...)
Never buy magic! Before you commit to a framework, make sure you could write it. Do this by actually writing something simple that does the basics that you need. Make sure the magic all goes away. And then look at the framework again. Is it worth it? Can you live without it?

Похоже вы не знаете про composer, там добавить нужную библиотеку достаточно одной команды

И никаких оберток

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

Например, если мы говорим про веб, внезапно понадобилось слать с клиента на сервер запрос к API в виде json+файл в аттаче (в том же запросе). Желательно использовать для этого multipart request, потому что альтернативный вариант, - это кодировать содержимое файла в base64 внутрь json-а, что повышает траффик (на 33%) и нагрузку на процессор (на over 9000%, потому что теперь придется парсить не 2 кб json, а 10 мб). А фреймворк на сервере умеет раутинг и еще много чего, но не умеет мультипарт. И есть сторонняя библиотека, которая умеет, но фреймворк про нее ничего не знает. И как будете их дружить без костылей?

Просто то же самое делается тем же количеством кода, но по-другому

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

Кроме того «по другому» может быть разным. Например DAO часто удобнее, чем просто голый SQL, хотя количество кода одинаковое.

находится баг или отсутсвие какой-нибудь маленькой, но очень нужной именно для этого проекта, фичи. Тогда начинаются танцы с бубнами, написание воркэраундов и оберток, и все становится грустно

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

фреймворки навязывают свою архитектуру

Для мартышек это огромный плюс, т.к. если им не навязывать они наворотят будь здоров. Обычно такое навязывание довольно условно, т.к. если разбираться как фреймворк устроен чуть глубже примеров из туториала, то всё ок. Современные фреймворки для пыха это вообще di-контейнер + набор компонентов, в первую очередь роутера и PSR-7, так что слепить из этого можно что угодно.

1 мультипарт умеют все фреймворки ибо это умеет php 2 фреймворк никак не ограничивает подключение библиотек, корме конфликтных случаев

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

Если говорить о пыхе, то фреймворк, если он современный, использует для разбора запроса компонент, который реализует какой-то интерфейс - PSR-7 или специфичный для фреймворка. Сам этот компонент фреймворк берёт из di контейнера, который инициализируется на стадии бутстрапа - что-нибудь вроде $app->set('request.class', \Request\Implementation::class). Т.е. чтобы подружить библиотеку с фреймворком, нужно написать врапер, который будет реализовать интерфейс который хочет фреймворк и в конфиге указать этот врапер. Либо, если всё на самом деле современное, библиотека, как и фреймворк должны использовать PSR-7 и тогда вообще ноль проблем, просто указываем в конфиге эту библиотеку, ну может быть ещё небольшую функцию специфичной для этой библиотеки инициализации.

Сложно? А теперь представь что код самописный и ты использовал одну библиотеку для реквеста (или вообще ни одной, лепил _POST) и тебе нужно прикрутить другую - вперёд, перелопачивать весь код от и до.

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

Если команда состоит из мартышек, то они и с фреймворком могут такого наворотить, что мама не горюй. В первую очередь заобъюзить его в доску и сделать в обход фреймворка все, что не поняли или не смогли. Так что фреймворк не панацея от говнокода. А если разработчики более-менее адекватные, то и код у них будет более-менее нормальный и с тестами.

набор компонентов

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

в первую очередь роутера

Роутер навязывает архитектуру еще как.

сделать в обход фреймворка все, что не поняли или не смогли

Это да, есть такое.

авторы фреймворка делают какие-то предположения о том, как это все будет работать

В современном мире это всё работает через DI используя стандартные (по возможности) интерфейсы.

Спасибо, почитаю. Вообще я тоже в некотором роде был против использования фреймворков из-за их ограничений. Об этом вы уже писали выше. Сейчас уверен, что лучше «подсмотреть» паттерн проектирования и создать свой фреймворк, но уже с требуемой архитектурой. Для себя пилю некий недоблог с админкой, всё это построено в стиле MVC или в нечто похожее на это.

мультипарт умеют все фреймворки ибо это умеет php

Это только пример. Мультипарт умеют, а что-нибудь еще не умеют. Как быть, если во фреймворке нет хука для подключения библиотеки, или вообще не предусмотрена в API какая-то функциональность?

фреймворк никак не ограничивает подключение библиотек, корме конфликтных случаев.

Ну вот, допустим, фреймворк ничего не знает про мультипарт и нет хука, чтобы его подключить. И в интерфейсе обработчика запроса, который дергает раутер фреймворка, нет аргумента attachments. Как быть? (если у тебя проблема с тем, чтобы абстрагироваться от мультипарта, то придумай что-нибудь другое, чего фреймворк может не уметь. Какое-нибудь шифрование или кэширование каких-нибудь данных, или statefull запросы, или еще что угодно).

Ответил здесь: А нужны ли фреймворки в php если он сам фреймворк? (комментарий)

Учитесь думать абстрактно, это помогает.

стандартные (по возможности) интерфейсы.

Вот тут-то и проблема. Что значит «стандартные»? А если в проекте нужно использовать что-то не «стандартное», то что тогда делать?

Убежать от фреймворка невозможно в том смысле, что в любом проекте больше ~1000 строк какой-то фреймворк возникнет сам, если не слишком говнокодить. Кое-что можно и нужно делать сторонними библиотеками, некоторые из которых тоже станут частью этого фреймворка. Самостоятельно писать libz или декодер mp3, например, не самая здравая идея. Или алгоритмы, имеющие отношение к криптографии (хотя учитывая количество багов в openssl, может быть лучше уже и самому писать).

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

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

фреймворк ничего не знает про мультипарт и нет хука, чтобы его подключить

обработчика запроса, который дергает раутер фреймворка

Выкинь нафиг этот говнокод и возьми нормальный фреймворк на DI. Кстати о чём вообще речь, что это за фреймворк такой?

Что значит «стандартные»?

Стандартные, значит утверждённые стандартом языка и иже с ним, как PSR в пыхе.

А если в проекте нужно использовать что-то не «стандартное», то что тогда делать?

Использовать врапер-адаптер. Для популярных вещей вероятность найти готовые адаптеры под разные фреймворки близки к 1.

возьми нормальный фреймворк на DI.

А если некуда инжектить депенденси, потому что фреймворк ничего не знает про функциональность, которая тебе нужна? Думай абстрактно, не зацикливайся на одном примере.

найти готовые адаптеры

А если тебе нужен интерфейс шире стандартного? Тут уже начинаются костыли. Я бы привел какой-нибудь простой пример, чтобы пояснить, но боюсь ты опять в него вцепишься и будешь доказывать, что именно этот пример не проблема, потому что конкретно это уже где-то решается.

А если некуда инжектить депенденси, потому что фреймворк ничего не знает про функциональность, которая тебе нужна? Думай абстрактно, не зацикливайся на одном примере.

Что значит некуда? Зависимости создаются при инициализации, которую ты сам и пишешь, это ж не магия какая-то. Если ты хочешь сказать, что фреймворк что-то берёт не из контейнера/фабрики и т.п., а просто имеет хардкод new SomeComponent() - то ещё раз, выкинь этот говнокод. Впрочем, выкинуть не всегда возможно, тогда да, жопа.

А если тебе нужен интерфейс шире стандартного?
фреймворк ничего не знает про функциональность, которая тебе нужна

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

вцепишься и будешь доказывать, что именно этот пример не проблема, потому что конкретно это уже где-то решается

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

А если тебе нужен интерфейс шире стандартного? Тут уже начинаются костыли.

На самом деле я понимаю о чём ты, недавно из-за такой вот фигни (мне нужно было, чтобы класс сообщения понимал дополнительный параметр), пришлось наследовать 2 класса, делать копипасту из суперкласса и менять код в контроллере. Но блджад, если бы автор этого поделия использовал DI, то всё обошлось бы 10 строчками, включая конфиг и ничего не пришлось бы ни копипастить, ни переписывать. Так что фреймворки бывают разные.

пришлось наследовать 2 класса

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

делать копипасту из суперкласса

Поздравляю, ты только что сделал костыль. Если завтра во фреймворке в этом коде исправят критическую уязвимость, ты этого фикса не получишь. То есть, ты про нее прочитаешь в новостях, откроешь себе таск в баг-трекере, обновишь версию фреймворка и с чистой совестью пометишь проблему, как решенную. Но нет. Или что-то изменят во фреймворке в новой версии, и твоя копи-паста после апдейта сломается. А отрефакторить по-человечески (добавить туда DI, например), чтобы избежать копи-пасты ты не смог, потому что архитектура фреймворка не позволила. О чем я и говорю.

На самом деле я понимаю о чём ты
если бы автор этого поделия использовал DI

Нет, не понимаешь. DI не панацея в тех случаях, когда некуда инджектить. Все-таки попытаюсь дать абстрактный пример. Вот нужно, чтобы фреймворк откуда-то изнутри себя дергал какую-то твою функцию, а во фреймворке нет кода, который будет ее дергать. Или нужно, чтобы в какую-то функцию передавал дополнительный параметр, которого в DI-интерфейсе просто нет, хотя нужные данные у фреймворка есть, и мог бы передать. Теперь представь себе, что эта функция вызывается во фреймворке в 50 разных местах. И что будешь делать? Копи-пастить все 50 классов? Или сразу форкать фреймворк и добавлять?

А отрефакторить по-человечески (добавить туда DI, например), чтобы избежать копи-пасты ты не смог, потому что архитектура фреймворка не позволила

Нет, мне было просто лень тогда. Кстати, чёрт побери, неплохая идея, запилю-ка я пулл реквест автору. Дело в том, что это плагин к фреймворку, в самом-то фреймворке DI во все поля.

Теперь представь себе, что эта функция вызывается во фреймворке в 50 разных местах

Да хоть в 100500, если она вызывается через DI мне вообще не нужно никуда лезть, а просто исправить одну строчку в конфиге, чтобы там везде вызвалась моя функция.

DI не панацея в тех случаях, когда некуда инджектить

Нет это ты не понимаешь. В современных пых фреймворках НЕТ таких мест. Там всегда можно и есть куда инжектить.

запилю-ка я пулл реквест автору

Если это не какая-то специфика твоего проекта, то почему бы и нет. Но бывают случаи, когда пулл-реквест не примут. И бывают часто.

нужно, чтобы в какую-то функцию передавал дополнительный параметр, которого в DI-интерфейсе просто нет

если она вызывается через DI мне вообще не нужно никуда лезть

Я понимаю, час поздний. Вызывается через DI, но без нужного дополнительного параметра.

Нет это ты не понимаешь. В современных пых фреймворках НЕТ таких мест. Там всегда можно и есть куда инжектить.

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

Вызывается через DI, но без нужного дополнительного параметра

Какая-то сильно специфическая ситуация, зачем нужно передавать ей дополнительный параметр если данные у фреймворка есть? Функция самостоятельно не может получить эти данные? Ну ок, для вызова годится любой callable, запихай в DI метод класса или вообще класс с __invoke и передавай дополнительно что хочешь. Типа функтора в крестах.

во фреймворке через строчку (буквально) должны стоять вызовы какого-нибудь DI интерфейса

Так и есть. Для облегчения кода там используют __get/__set, в итоге все выглядит как $app->request->body вместо $app->get('request')->get('body'), где $app это di контейнер.

зачем нужно передавать ей дополнительный параметр если данные у фреймворка есть?

Например затем, что эти данные нужны твоей бизнес-логике, а фреймворк об этом не знает.

Функция самостоятельно не может получить эти данные?

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

передавай дополнительно что хочешь

Я не могу передать. У моего кода этих данных нет, я как раз и хочу получить их от фреймворка.

Вообще, мы скатились в какое-то беспредметное переливание из пустого в порожнее. Ситуации, когда чего-то во фреймворке не хватает, бывают, ты сам с такой ситуацией столкнулся недавно и был вынужден запилить костыль. Если бы ты не поленился и отрефакторил фреймворк или плагин, тебе пришлось бы после этого поддерживать свою отрефакторенную версию, что еще затратнее. Отрефакторить только свой код ты не мог, потому что проблема была не в нем (если я правильно тебя понял). Ты теперь пытаешься меня убедить, что в современных фреймворках такого не происходит и таким образом сам себе противоречишь. Так о чем мы спорим?

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

Ситуации, когда чего-то во фреймворке не хватает, бывают

Бывают, но это ровно такие же ситуации которые бывают без фреймворка, т.к. фреймворк тут никак ситуацию не ухудшает. Мы с тобой сейчас договорились, что да, функция в пыхе не может получить доступ к результату локального вычисления. Ок, не может. А без фреймворка может? Мне не придётся копипастить и переписывать половину кода, где эта функция используется? К слову сказать, во фреймворках не придётся т.к. пишут их разумные люди, и функции размером в 10 экранов там не встречаются, что сильно уменьшает вероятность того, что потребуются какие-то локальные данные, просто потому что их там мало. А с другой стороны если уж и приходится подменять всю объемлющую функцию где делаетя вызов, то по крайней мере копипасты получается немного и уж точно не приходится лезть внутрь и что-то там менять.

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

Мне и так её приходится поддерживать. Было бы гораздо менее затратно, потому что не было бы копипасты и код контроллера не отличался бы от «непатченного» варианта.

Ты теперь пытаешься меня убедить, что в современных фреймворках такого не происходит

В современных не происходит. Тот был не современный, о чём я и написал, что проблемный код староват.

Так о чем мы спорим?

О том, что фреймворки делают хуже больше, чем лучше. При правильном подходе не делают - 90% проблем решаются очень просто, остальные 10%, хм, решаются. Ситуаций когда нужно прям переписать пол-фреймворка не бывает.

Вообще не понял, к чему ты это

К тому, что снаружи не очевидно, что это di-контейнер и можно подумать, что это хардкод.

сайт-визитка получится не очень без фреймворка

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

Какого в анус жопы динамического контента в портфолие? Ты вообще знаешь что такое этот «динамический контент»?

Хотя если тебе хостинг за 90р в месяц «это дорого», то лучше иди слесарем на завод работать.

Анимации на жквери вызывают ненависть не у снобов.
Но чтобы понять причины — нужны мозги в голове.

Goury ★★★ (30.10.2016 8:16:02) Илитка; Срал я на PEP8 и на его рекомендации. Я пишу код так, чтобы хотелось ещё и чтобы было удобно и приятно.

Тебе ли говорить об этом?

внезапно понадобилось слать с клиента на сервер запрос к API в виде json+файл в аттаче (в том же запросе).

Ты описываешь json rpc и для него под загрузку лучше выделять вообще отдельный сервис, либо передавать bson.

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

Подобный фреймворк просто никто не будет использовать. Крупные в любом случае будут иметь мультипарт ридер. Микрофреймворки тоже, либо имеют систему с мидлухами, где можно к пайпе присосать что угодно.

Нужны. Ведь php сам по себе — шаблонизатор, а это всего лишь часть фреймворка.

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

Мнения есть разные, только в твоем случае нужно учиться, а не смотреть у кого какое мнение и принимать на веру. Изучи мануал по php на php.net, потом начни изучать какой-нибудь фреймворк. Что-нибудь подходящее для новичков и с простыми концепциями, Yii2, например (это не значит, что yii2 только для новичков и простых проектов). Yii хорош тем, что ты всегда можешь залезть в код самого фреймворка и там все предельно понятно, без нагромождения кучи слоев абстракций и жонглирования di контейнерами. Потом сам поймешь, в чем фреймворк упрощает тебе жизнь, а в чем нет.

Не слушай «экспертов», хвалящих каждый своё болото, разберись сам во всем.

Каждый сам для себя решает.

900 рэ в год/ 500 рублей в месяц

Какого в анус жопы динамического контента в портфолие? Ты вообще знаешь что такое этот «динамический контент»?

А кто сказал что у меня портфолио? Говнобложек же. Контент меняется в зависимости от кликов/наведений или по фазе луны. Сейчас так модно, ничего не понимать и разбрасываться терминами =)

И да, слесарем я бы больше зарабатывал, чем на говновизитках. Но инвалидов в слесари не берут =)

Мозги в голову не добавили, так что анимации на «жквери» вызывают ненависть у меня, например.

Смотря какой фреймворк, они разные, можешь выбрать наиболее легкий, «минималистичный» из них. А сайт-визитку я делал на голом пыхе с костылями на изоленте. Это как бы не интернет-магазин, чтобы так усложнять, применяя фреймворки.

VPS от хорошего провайдера не может стоить 90р. Ты не перегибай, «дружище»

А брать дешевые и наслаждаться нестабильностью и падениями я не собираюсь.

Зачем нужен PHP, если он написан на Си? Можно сразу писать на Си.

Зачем нужен Си, если он компилируется в машинные коды? Можно сразу писать в машинных кодах.

...

Если вопрос не ради троллинга, а от реального незнания, то:

1. PHP не фреймворк. Он тянет максимум на шаблонизатор, а это только один из компонентов фреймворков.

2. Некоторые фреймворки используют PHP в качестве шаблонизатора, но это не самая удачная идея, так как, с одной стороны, обеспечивает меньше возможностей (например, на PHP-шаблонизаторе не реализуешь наследование, переопределяемые блоки, не разделишь код от представления, что бывает нужно при допускании не-программистов к дизайну), с другой, нередко, может привести даже к падению производительности. Скажем, при сборке шаблона из компонентов, на чистом PHP придётся загружать их по include на каждом запросе, создавая повышенную нагрузку на дисковую подсистему, в то время как нормальные шаблонизаторы компилируют все исходные модули в один PHP-файл, оптимизируя загрузку.

А нужен ли PHP, есть есть Python/Ruby/JavaScripy/Clojure/Perl?

— А нужен ли Python, есть есть PHP/Ruby/JavaScripy/Clojure/Perl?

— А нужен ли Ruby, есть есть PHP/Python/JavaScripy/Clojure/Perl?

— А нужен ли JavaScripy, есть есть PHP/Python/Ruby/Clojure/Perl?

— А нужен ли Clojure, есть есть PHP/Python/Ruby/JavaScripy/Perl?

— А нужен ли Perl, есть есть PHP/Python/Ruby/JavaScripy/Clojure?

во фреймворке через строчку (буквально) должны стоять вызовы какого-нибудь DI интерфейса

Так и есть. Для облегчения кода там используют __get/__set, в итоге все выглядит как $app->request->body вместо $app->get('request')->get('body'), где $app это di контейнер.

Нормальный фреймворк, ИМХО, должен брать задачу контроллера на себя. Вся эта фигня с $app->request()->body() (я предпочитаю такой формат :D) должна скрываться под капотом фреймворка и без нужды не вызываться. 90% типовых задач могут вообще задаваться описательно на YAML. Типа, например, страница админки со списком элементов (чтобы их редактировать/создавать и т.п.):

extends: \App\Admin\Meta\Main

<?php

namespace Aviaport\Admin\Smm\Publish;

class Main extends \Aviaport\Admin\Meta\Main
{
}

<?php

namespace Aviaport\Admin\Smm\Publish;

class Edit extends \Aviaport\Admin\Meta\Edit
{
}

<?php

namespace Aviaport\Admin\Smm;

class Publish extends ObjectDb
{
    var $class_title = 'Публикация';
    var $class_title_vp = 'публикацию';

    function table_name() { return 'smm_publishes'; }

    function table_fields()
    {
        return [
            'id',
            'title' => ['title' => 'Название'],
            'text' => ['title' => 'Содержание', 'rows' => 15],
            'publish_status_id' => ['title' => 'Состояние', 'class' => Publish\Status::class],
            'create_time' => 'UNIX_TIMESTAMP(`create_ts`)',
            'modify_time' => 'UNIX_TIMESTAMP(`modify_ts`)',
            'last_editor_id',
            'last_editor_ip',
        ];
    }
}

Потому что рукожопы обезъянопыхи не осилили халявный OpenShift с парой гигов оперативы и несколькими ядрами

Насколько долго продержится халява — вот в чем вопрос.