Сейчас очень мало информации о CakePHP 2.0 и особенно о суперновом 3.0, так что я решил провести небольшое интервью с Nate Abele, ведущим разработчиком CakePHP.

Привет, Nate, CakeFest завершился и слух об анонсе CakePHP 2.0 и Cake 3 постепенно распространяется. Можешь рассказать в общих чертах, что будет в новых версиях?

CakePHP 2.0 — это обновление текущей версии 1.x с переходом на строгую совместимость с PHP5, что означает, помимо выгоды от избавления от излишнего кода для поддержки PHP4, повышение производительности примерно на 25%.

Cake 3, с другой стороны, значительно отличается от текущей версии по ряду параметров. В основном тем, что с нуля переписан на PHP 5.3.

CakePHP 2.0 будет совместим с 1.x? Мы уже пережили значительный апгрейд с 1.1 на 1.2, апгрейд на 2.0 видимо будет еще более тяжелым?

Вообще-то, нет. CakePHP 2.0 будет практически 100% совместим на уровне API с грядущим CakePHP 1.3, который, в свою очередь, будет совместим с 1.2, за исключением некоторых устаревших (но еще работающих) методов.

Также, на случай миграции с 1.2 на 1.3/2.0, у нас есть инструкция, в которой будет сказано, какие небольшие изменения нужно будет внести в код существующих приложений.

Круто, то есть будет халявный прирост производительности для всех существующих 1.2 приложений?

Именно что.

Хорошо, вернемся к 3.0. Расскажи-ка немного о фундаментальных изменениях в PHP как языке и о том, как они повлияли на новое ядро CakePHP.

Ну, для CakePHP, переход от совместимости с PHP4 прямо на php5.3 — это очень большой шаг, не только из-за новых фич 5.3, но также и из-за фич PHP5, которыми мы наконец-то сможем воспользоваться.

Одна из важных фич PHP5.3, которая повлияла на новую архитектуру — пространства имён. Новое ядро организовано в виде пакетов, каждый из которых состоит, в свою очередь, из других пакетов.

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

Другая фича — замыкания. Замыкания — это анонимные функции (то есть функции, присвоенные свойству класса или переменной), которые могут наследовать контекст области видимости, в которой они объявлены. Это позволяет нам внедрять необходимую функциональность прямо в классы и методы, и в Cake3 мы используем их в системе фильтров.

В новом ядре, множество методов объектов реализуют систему фильтров, что позволяет привязывать произвольную функциональность прямо к вызовам методов: модифицировать параметры и возвращаемые значения.

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

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

Можно пример?

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

В Cake3 я могу сделать так:

applyFilter(‘_execute’, function($self, $params, $chain) {
    $out = fopen(‘php://stderr’);
    fwrite($out, $params['sql']);
    fclose($out);
    return $chain->next($self, $params, $chain);
});

Здесь я получаю объект БД из класса Connections (это эквивалент вызова ConnectionManager::getDataSource() в 1.2) и присоединяю фильтр, который перехватывает метод _execute(). После этого, я мог бы отправить вывод в класс логгинга, но сейчас я просто хочу вывести запросы в лог ошибок, чтобы быстренько посмотреть что да как. Фильтр будет применен каждый раз, когда запрос отправится в БД, таким образом все запросы будут записаны, как я и хотел.

Получается, что фильтры можно применить только к объекту, а не к классу?

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

Кроме того, в ядре появится новый класс — Collection. Этот класс похож на массив, но с дополнительными полезностями, наподобие вызова метода у всех содержащихся в нем объектах при вызове метода у самого класса коллекции. Таким образом, возможно применить фильтр у множества объектов сразу используя такую технику.

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

Да, в чем-то модели поменяются, а в чем-то — нет. Например, записи по-прежнему будут получаться чем-то наподобие $posts = Post::find(«all»); Это и все связанное с моделями должно быть сразу же понятно любому, кто сейчас работает с кэйком.

Но внутри, модели будут полностью новыми. Теперь они будут взаимодействовать с источниками данных через ограниченный набор методов с помощью объектов Query. Эти объекты очень полезны, так как они позволяют нам инкапсулировать большую часть работы по генерации запросов, которая раньше была разбросана по нескольким разным классам. Кроме того, так как query-объекты работают с уровнем данных и так как объекты ядра могут быть заменены пользовательскими, то пользователи могут легко модифицировать и расширять синтаксис SQL, поддерживаемый кэйком.

С помощью упоминавшегося класса коллекций, результаты запроса стали объектами, причем объектами стали не только записи, но и наборы записей. Объект RecordSet, потомок Collection, похож на массив в том смысле, что можно пройтись по нему foreach сотоварищи. Но он также имеет и значительные улучшения, наподобие ленивой подгрузки записей по мере надобности. Эта его особенность отражает архитектурное решение — во всех частях фрэймворка, где это только возможно, используется новая более объектно-ориентированная архитектура, причем ленивая.

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

Если записи теперь объекты, получается что CakePHP получит полноценную реализацию ActiveRecord?

Ну да. С новой фичей PHP5.3 — Late Static Binding мы можем обращаться к статическим классам, как показано выше.

Хорошо. Моя личная цель — прекратить испльзовать реляционные БД для неструктурированных данных в 2009 году. В Cake3 будет поддержка чего-нибудь такого?

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

Невероятно! И когда же мы получим все эти крутанские штуки? Есть какой-нибудь план по выпуску Cake3?

Хотя код доступен непосредственно на code.cakephp.org, трудно сказать когда будет официальный релиз. Но ожидайте значительного объема работы в ближайшие месяцы.

У Cake3 появились новые фичи и новые требования к серверной части. Что если сравнить его с такими фремворками, как Ruby on Rails, Django и тд?

Ну, миграция с PHP 5.2 на 5.3 быстрая и безболезненная, так как в области существующих фич мало что изменилось. Как всегда PHP — это самая простая в использовании и самая простая в развертывании платформа в вебе. Разместить сайт — это всего лишь скопировать файлы в корень сайта.

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

Это перевод, оригинал — здесь

Ссылки: CakePHP 2.0 — http://code.cakephp.org/cakephp2 Cake3 — http://code.cakephp.org/cake3