HMVC в PHP: как начать использовать?

Question

[Дмитрий Щербаков]

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

Вот хорошая статья https://habrahabr.ru/post/113117/ увидел куски кода и прям все так понравилось, но увидев фразу "Один из них – Kohana PHP третьей версии, который изначально создавался с ориентацией на HMVC. Далее во всех примерах я буду использовать этот фреймворк." пришло разочарование, а если мы не хотим использовать Kohana (она кстати вроде сдохла давно) или вообще не хотим использовать фреймворк (проект будет собран на библиотеках + HMVC) как раз чтобы было меньше связанности в коде.

И вот вопрос, может есть какая библиотека которая реализует готовый объект Request который там здорово используется в статье?

Comments

[copal]

Вы должны понять одно - не существует HMVC, это полный бред! Представьте что я продаю Вам холодильник и прилагаю к нему инструкцию в которой написано = открыть дверцу, достать хранимый в нем продукт, закрыть дверцу. То же самое сделал автор MVC, он рассказал что такое mvc и приложил к ней "инструкцию".
И вот Вы купили мой холодильник, легли спать, а на утро обнаружили на столе записку, что Ваш любимый завтрак (яичницу) придется готовить самому. И вот Вы открываете дверцу, берете одно яйцо, закрываете дверцу. Затем снова открываете дверцу, берете ещё одно яйцо, закрываете дверцу. А вдруг Вы любите яичницу из трех яиц? По это - Вы снова открываете дверцу, берете яйцо, закрываете дверцу.
Естественно Вам это не нравится, но тут вдруг приходит в голову идея создать свой холодильник в инструкции к которому будет написано - открыть дверцу, взять три хранимых единицы, закрыть дверцу.
Это по Вашему нормально? Вот и с HMVC такая же история. Автор mvc предполагал что нужно написать миллион инструкций для каждого и не знал что найдется тот, кто сможет придумать такую херню.

[copal]

И на сервере нет возможности делать композицию представлений, такую как на клиенте, по этому я только что изобрел новую парадигму - MVVC, это уникальная парадигма, у которой как видно из названия представления могут быть в виде композиции. Хотя а вдруг композиция будет вложенной? Тогда это будет уже MVVVC!

[copal]

Сегодня прям день открытий! Вот я подумал, а что если контроллеры не будут иметь жесткие ссылки друг на друга, а будут использовать событийную модель для низкой связанности? Тогда это уже EMVCVVCE.

[Антон Шаманов]

copal: Ого! да среди нас сам Джон Гроссман! :)

[Антон Шаманов]

copal: если бы мы не давали имена вещам, то тебе бы звали не copal, а это и это имело бы.. это это с это ...в смысле, кучу проблем с общением

Answer 1

[Антон Шаманов]

Никто не запрещает использовать kohana\core как отдельную библиотеку, hmvc реализуется на большинстве фреймворков, например на yii. Это же паттерн, он не привязан к какому-либо фреймворку.

Comments

[Дмитрий Щербаков]

Антон Шаманов Я кажется вопрос не так составил. Я знаю что HMVC это паттерн. Хочу использовать его в своем проекте, но мозгов не хватает написать реализацию самому. Вот думал что есть готовая реализация без привязки к фреймворкам. То что многие фреймворки это у себя реализовали тоже знаю. Не знаю как это реализовать у себя.

А то вот для роутинга куча отдельных библиотек, а вот для HMVC такого похоже нет.

[Антон Шаманов]

DimNS: Вы видимо не совсем поняли принцип HMVC по сути это вызов из основного контроллера дополнительных по средствам запросов, например, я в своих проектах в основном view вызываю запросами контент виджетов (последние новости, корзина магазина) . Этот принцип реализуется даже с помощью банального fopen(), который принимает и ссылки т.е. подойдет любая библиотека для создания и обработки запросов (лучше всего реализующая PSR-7 www.php-fig.org/psr/psr-7 )

[Дмитрий Щербаков]

Антон Шаманов: ну вот это я как раз понял, именно поэтому мне и нравится HMVC и я хочу его использовать потому что в будущем будут некоторые элементы выделяться на другие серверы и доступ станет вместо внутреннего внешним. По сути нужна библиотека реализующая возможность создавать и обрабатывать запросы как внешние (во фреймворках используют curl) так и внутренние, просто вызов соответствующего контроллера. Вот я посмотрел на реализацию в Kohana и это круто, там столько всего что самому такое реализовать не наделав глюков по пути мне сложно.

[Антон Шаманов]

DimNS: а какая тебе разница внешние или внутренние? все равно ты получаешь конечный результат в виде html\xml, так что просто сделай класс-обертку для создания запросов curl'ом и за дело.
Т.е.

Новости:
<?=(new myRequest('mysite.ru/widget/news')->execute())?>
<?=(new myRequest('google.com/widget/news')->execute())?>

[Антон Шаманов]

DimNS: Либо как я уже писал возьми Kohana\Core это все равно лучше чем писать самому

[Дмитрий Щербаков]

Антон Шаманов: не-не-не как это какая разница, внешний идет через curl, а внутренний идет в соответствующий контроллер без всяких curl чтобы не создавать http соединение ведь в этом прелесть подхода, что в любой момент времени можно любой запрос сделать как внешним так и внутренним

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

P.S. блин мне кажется я неправильно выражаюсь, может начать с головы
сейчас в моем проекте есть папка classes там толпа разных классов отдельных модулей проекта, полный бардак, каждый метод класса используется где захочет, т.е. нет никаких фасадов, и вот я думал что с помощью HMVC смогу привести все в порядок, может я вообще не то выбираю, может мне HMVC вообще не нужен, а просто разбить все блоки на модули (с помощью namespaces) сделать для каждого модуля фасад и в приложении использовать модули только через фасады (фасады хранить в отдельной папке вместе с приложением и уже внутри фасада писать как обращаться к этому модулю по внутреннему запросу ил по внешнему)

[Антон Шаманов]

DimNS: Если ты собираешься переносить часть кода на далееекие севера :) , то все все равно потребуется организовывать запросы к ним и никакие фасады тут не помогут. А вот разбитие кода по независимым модулям поможет т.к. облегчит их переезд на Магадан в случае чего.. По поводу самих запросов советую почитать спецификацию REST\WDSL (первый вариант попроще наверное будет). Основной смысл всего выше сказанного - ослабить связь между классами, если все упирается в это, то HMVC не единственное решение и вообще не решение т.к. перед тем как начать его использовать нужно создать соответствующее окружение.

[Дмитрий Щербаков]

Антон Шаманов: часть кода переноситься не будет, переноситься могут только целиком модули. Да как раз и хочу ослабить связи, да вот я выбрав HMVC как решение и уперся в то что нет соответствующего окружения. А что может вместо HMVC помочь мне избавиться от связности при этом хочется как-то так организовать код чтобы он был прям в отдельных папках (в идеале модули вообще не будут общаться между собой, для этого будет само приложение, оно будет рулить от кого что получить и кому это отдать),

т.е. допустим есть страница domain.tld/page ей что-то нужно получить от одного модуля, передать другому, получить от него данные отправить в третий модуль и уже после третьего все это собрать и выдать на страницу.

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

P.S. похоже я вообще не в ту сторону смотрю

[Антон Шаманов]

DimNS: Вначале надо привести модули к определенному виду, например, обеспечить REST получение\отправку данных модулями т.е. нужно снабдить основные модели REST контроллерами.

[Дмитрий Щербаков]

Антон Шаманов: Вот такую я придумал структуру, если вдруг какой-то модуль нужно будет вынести на отдельный сервер, то нужно будет в фасаде прописать обращение к нему через CURL и все, ну и если этот модуль общался с другими модулями то внутри прописать, что теперь он с ними будет по REST API общаться. Т.е изначально заложено что к любому модулю можно обратиться как внутренним запросом так и через внешний REST API

[Антон Шаманов]

DimNS:
1. Зачем нужен контроллер фасадов если есть API запрос?
2. Чем больше абстракции, тем меньше скорость. Взять например fb\vk они используют процедурный подход (+самописные версии php) и денормализованные бд.
Т.е. надо сразу прикинуть какие модули потом будут перенесены на внешние сервера и добавлять взаимодействие через API только для них, остальные же должны работать напрямую с внутренними модулями.

[Антон Шаманов]

DimNS: Вместо схемы лучше сделай набросок кода с классами-пустышками, так будет намного проще.

[Дмитрий Щербаков]

Антон Шаманов:
1. Чтобы точка входа как внутри так и снаружи была одна, хотя да, сейчас взглянул еще раз и действительно контроллер фасадом лишний, спасибо
2. Да это понятно, вот поэтому сейчас проект из себя представляет сборище просто классов, скорость конечно скоростью но сейчас задумались о расширении штата программистов и поддерживать все это чудо будет адом
3. А вот тут такая загвоздка, допустим есть модуль который сейчас в принципе простой и лежит вместе с основным приложением, а например через год его дописывали дописывали а до такого надописывались что решили ну нафиг надо его на отдельный сервер перенести (хотя может быть так что просто сам модуль в корне неверный раз так распух и наверно тот кусок что стал большим должен стать отдельным модулем и уехать на луну)

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

[Антон Шаманов]

DimNS: В данном случае своеобразным фасадом выступает контроллер. "3. А вот тут такая загвоздка" - для этого и существует рефакторинг, если модуль написан грамотно, то дописать к нему rest api не составит проблемы. Вообще нужно понимать что в основном с сервера выносятся данные и не всегда есть необходимость в переносе кода, доступ с основного сервера к ним можно получить, например, по ftp\http. И вообще если опыта нет, то даже прочтение соответствующей литературы и советы не всегда помогают, все равно придется переписывать и не раз.

[Дмитрий Щербаков]

Антон Шаманов: вот разродился структурой файлов, скелет даже работает, можно запустить ))
архив Доступ ко всем модулям через их фасады, чтобы всегда был один вход в модуль, при этом неважно находится модуль на этом же сервере или на другом, и даже неважно php это или уже написано все на perl допустим, за все это отвечает фасад модуля. Вот хочу чтобы проект был такого плана, чтобы легче было поддерживать все эти кубики

[Антон Шаманов]

DimNS:
1. Закрывающий тег ?> нужен только в нативных view файлах. Заголовки (headers) должны содержаться в response объекте контроллера и выводится при его отображении (метод __toString). Начальный слэш в строках аля "\MyApp\Pages\Page1\Controller::index()" не требуется, он добавляется для того чтобы избежать совпадения имен с классами php:

namespace MyApp;
class ArrayObject extends \ArrayObject {}

2. Начни использовать git: заведи аккаунт на https://github.com и размещай проект там. Клиент https://desktop.github.com .
3. Старайся не использовать статику без крайней надобности, иначе это уже не ООП. Выноси статические методы\свойства в отдельные классы-хэлперы.
4. Вначале создаются интерфейсы\абстрактные классы, а затем уже классы-пустышки, они должны содержать основные методы симулирующие их реальную работу.

<?php 

namespace Author\Package\HTTP;

interface RouteInterface
{
    public function __construct($name, $regExpUri, array $regExpParams = [], array $defaultParams = []);
    /**
     * Проверка ссылки на соответствие роуту.
     * @param string $uri
     * @return this
     */
    public function checkUri($uri);
    /**
     * @param string $name
     * @param mixed $default
     * @return mixed
     */
    public function getParam($name, $default = null);
    /**
     * @param string $name
     * @return bool
     */
    public function existsParam($name);
    /**
     * @return array
     */
    public function getParams();
}

interface ResponseInterface
{
    const STATUS_100 = 'Continue';
    // ...
    const STATUS_200 = 'OK';
    // ...
    const STATUS_300 = 'Multiple choices';
    // ...
    const STATUS_400 = 'Bad request';
    // ...
    const STATUS_500 = 'Internal server error';
    /**
     * @param array $options
     * @return void
     */
    public function __construct(array $options = array());
    /**
     * @param string $name
     * @param string $value
     * @return this
     */
    public function setHeader($name, $value);
    /**
     * @param string $name
     * @return array|false Array of values or false if not set
     */
    public function getHeader($name);
    /**
     * @param bool $rewrite
     * @return this
     */
    public function sendHeaders($rewrite = false);
    /**
     * @return int
     */
    public function getStatus();
    /**
     * @param int $code
     * @return this
     */
    public function setStatus($code);
    /**
     * @param string $body
     * @return this
     */
    public function setBody($body);
    /**
     * @return string
     */
    public function getBody();
    /**
     * @return string
     */
    public function __toString();
}

interface RequestInterface
{
    const GET     = 'GET';
    const POST    = 'POST';
    const PUT     = 'PUT';
    const DELETE  = 'DELETE';
    const HEAD    = 'HEAD';
    const OPTIONS = 'OPTIONS';
    const TRACE   = 'TRACE';
    const CONNECT = 'CONNECT';
    /**
     * @param string|true $uri If true when it's initial request
     * @param array $options
     * @return void
     */
    public function __construct($uri, array $options = array());
    /**
     * @return ResponseInterface
     */
    public function execute();
    /**
     * @return string
     */
    public function getMethod();
    /**
     * @param string $method
     * @return this
     */
    public function setMethod($method);
    /**
     * return $this->execute();
     * @return string
     */
    public function __toString();
}

interface ControllerInterface
{
    /**
     * @param RequestInterface $request
     * @param ResponseInterface $response
     * @return void
     */
    public function __construct(RequestInterface $request, ResponseInterface $response);
    /**
     * @return ResponseInterface
     */
    public function execute();
    /**
     * @return void
     */
    public function beforeAction();
    /**
     * @return void
     */
    public function afterAction();
}

interface ExceptionInterface
{
    /**
     * @param RequestInterface $request
     * @return this
     */
    public function setRequest(RequestInterface $request);
}

class Exception extends \Exception implements ExceptionInterface
{
    /**
     * @var null|RequestInterface
     */
    protected $request; 
    /**
     * @var array Error code => name
     */
    protected $errors = [
        E_ERROR              => 'Fatal error',
        E_WARNING            => 'Warning',
        E_PARSE              => 'Parse error',
        E_NOTICE             => 'Notice',
        E_USER_ERROR         => 'User error',
        E_USER_WARNING       => 'User warning',
        E_USER_NOTICE        => 'User notice',
        E_STRICT             => 'Strict',
        E_RECOVERABLE_ERROR  => 'Recoverable error',
        E_DEPRECATED         => 'Deprecated',
        E_USER_DEPRECATED    => 'User deprecated'
    ];

    /**
     * @return array
     */
    final public function getErrors()
    {
        return $this->errors;
    }

    /**
     * @param RequestInterface $request
     * @return this
     */
    final public function setRequest(RequestInterface $request)
    {
        $this->request = $request;
        return $this;
    }
}

Router::getInstance()->setRoute(new Route(
    'default', // Имя роута
    '(<directory>/(<controller>/(<action>/(<id>/))))', // RegExp для пути
    [ // RegExp для проверки параметров
        'directory'  => '[0-9a-zA-Z]+',
        'controller' => '[0-9a-zA-Z]+',
        'action'     => '[0-9a-zA-Z]+',
        'id'         => '[0-9]+'
    ],
    [ // Значения по умолчанию
        'directory'  => 'Frontend',
        'controller' => 'Page',
        'action'     => 'Index'
    ]
));
// Первичный запрос
$request = new Request(true, $_SERVER);
// Получение ответа
$response = $request->execute();
// ... и его вывод на экран
echo $response->sendHeaders(true)->getBody();

[Дмитрий Щербаков]

Антон Шаманов: крутооо )) вот только вы пошли в дебри, я это написал чисто как шаблон, я не буду проект писать прям уж так с нуля, например для роута будет использоваться klein.php.

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

По поводу статики, ООП ради ООП тоже не есть хорошо.

[Антон Шаманов]

DimNS: Это куски кода из классов которые я использую в проектах. По поводу размещения файлов: модули должны соответствовать PSR-4 + контроллер лучше реализовать на основе моего ControllerInterface. По статитике: в данном случае смысла в ней нет, только лишняя память расходуется, также советую ознакомиться с https://r.je/static-methods-bad-practice.html

[Дмитрий Щербаков]

Антон Шаманов: спасибо за статью, поучительно, действительно наконец-то хоть кто-то расписал на пальцах почему и зачем.

вылил свою поделку на GitHub

начал приводить код к PSR-2, потихоньку избавляюсь от статики (но пока один магический класс оставил, курил DI но так и не вкурил до конца как его использовать)

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

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

Уважаемый Антон Шаманов можем мы с вами перейти на общение в скайпе например? Хочу попросить вас помочь мне с этим скелетом.

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

[Антон Шаманов]

Дмитрий Щербаков: тут https://github.com/WinterSilence есть почта, пиши - вышлю контакты