Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Как работает PHPixie — Жизнь одного запроса, контейнер и парадигма

Anna | 31.05.2014 | нет комментариев

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

Как и скажем Symfony, PHPixie состоит из 2-х частей: библиотеки компонентов и базового плана, правда в случае PHPixie базовый план больше тонкий и состоит каждого из нескольких файлов. Он тут исполняет роль примера и следственно метаморфоза его под себя не только приветствуется но в некоторых случаях даже нужно. Именно для этого значимо понимать что и как происходит в системе. Применяя свои несколько ограниченные знания в области рисования я подготовил диаграмму обработки запроса

PHPixie

Безусловно тем кто теснее знаком с MVC (либо даже VC в этом случае, так как модели я не нарисовал) наверно эта схема теснее покажется знакомой, но для новичков может быть дюже пригодна. Выходит начнем c index.php куда и попадают все запросы, тут самые значимые строчки это:

$pixie = new AppPixie();
$pixie->bootstrap($root)->handle_http_request();

И сразу же мы попадаем на самую главную часть, класс AppPixie тот, что является сердцем фреймворка, его DI контейнером. Через него дозволено получить доступ ко каждому иным компонентам. AppPixie наследует от PHPixiePixie из библиотеки PHPixie-Core. Базовый план оглашает данный класс взамен применения PHPixiePixie напрямую для предоставления разработчику вероятности внести в него свои метаморфозы ( скажем подключить модуль).

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

Способ bootstrap() инициализирует $pixie, считывает конфигурацию, подключает обработку исключений итд. Как раз в handle_http_request() проходит обработка запроса. Данный процесс состоит из 3 этапов:

  • Создание объекта $request класса PHPixieRequest
  • Данный объект передается в соответствующий контроллер и выполняется соответствующий action
  • В процессе исполнения екшена контроллер изменяет объект $response ( PHPixieResponse )
  • Данные из $response (хедеры и контент) отсылаются пользователю

Все три самых значимых объекта $request, $response и $pixie доступны как признаки класса PHPixieController. Сейчас отвлечемся немножко на еще несколько парадигм написания кода на PHPixie:

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

Не применять статические проперти и способы. Применение статики крепко усложняет написание тестов. Применяя PHPixie дозволено легко обойтись без них, довольно добавить экземпляр как признак AppPixie и вы сумеете получить к нему доступ фактически из всякого места. Таким образом мы реально получим синглтон. Кстати сделать это дозволено еще путем добавления его в $instance_classes.

namespace App;
class Pixie extends PHPixiePixie {
    public function __construct() {
           $this->instance_classes['singleton'] = 'AppSingleton';
    }	
}

// Сейчас мы можем применять $pixie->singleton в любом месте,
// и неизменно получить тот же объект. В качестве добавочного бонуса
// объект будет сделан только тогда когда он будет необходим
Как работают модули

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

namespace App;
class Pixie extends PHPixiePixie {
	protected $modules = array(
		'db' => 'PHPixieDB',
		'orm' => 'PHPixieORM'
	);
}

// Сейчас мы можем применять $pixie->db и $pixie->orm 

А что делать если я скажем хочу подменить класс PHPixieORMModel на свой AppModel? Все легко, нужно еще сделать свой AppORM (extends PHPixieORM ) способ get() которого взамен модели PHPixieORMModel будет возвращать ту что необходима нам. в этом еще огромнее проявляется одна из идей фреймворка — как дозволено огромнее применять типовые приемы ООП взамен каких-то магий. Скажем Дабы подменить класс самого фреймворка доводится использовать subclass_prefix и делать єто на ярусе конфигурации а не собственно программирования. Такой подход разрешает гораздо улучшыть осознавание системы, так как по большей части в флове дозволено разобраться не зная ничего о фреймворке, легко посмотрев на сами классы.

А как же хуки, ивенты и другое?

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

В дальнейшей статье я либо больше детально разгляжу как PHPixie работает с базами данных, либо больше расширенно расскажу в чем плюсы и минусы линейного вопреки event driven программирования.

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB