Пробная версия Zend Framework 2

Погружение в код

Поскольку я хорошо знаком с Zend Framework 1, я решил перейти на бета-версию 2.x, чтобы узнать, что изменилось и как это влияет на мои существующие приложения.

Пошаговое руководство Роба Аллена, вероятно, является отправной точкой, также для людей, которые никогда не использовали Zend Framework. Вы можете установить с помощью git-клонирования (или с помощью zip-файла) скелетное приложение, готовое для добавления модулей.

Если вы хотите поиграть с уже написанным приложением, вместо этого возьмите результат урока, содержащий модуль Album, который выполняет CRUD над таблицей базы данных. Это более функционально и реалистично, чем Hello World.

Скелетное приложение — хороший ход, так как оно уже включает в себя функциональное приложение и .htaccess, поэтому вам нужно всего лишь немного настройки Apache, чтобы запустить его. Раньше генерация кода была способом настроить приложение Zend Framework 1 для новичка, и я не могу сказать, что заставить Zend_Tool и двоичный файл zf работать было так просто с первой попытки.

Заметным изменением в структуре приложения является компоновка модуля:

Application/
    config/
    src/
    views/

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

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

стандарты

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

• Будучи только в PHP 5.3, классы организованы в пространства имен, а не только в виртуальные пакеты, разделенные подчеркиванием.
• Автозагрузка PSR-0 принята во всех модулях src / folder, поэтому нет несоответствия между классами и именами файлов.
• больше нет суффикса интерфейса для имен.
• маркерные интерфейсы для исключений , так что исключения PHP 5.3 используются наследованием, а исключения связаны с модулем посредством реализации интерфейса (например, Zend \ Json \ Interface).
• нет префикса подчеркивания для частных и защищенных свойств и методов.

Ничего революционного, но это освобождает от некоторых трудностей при написании нового кода.

Не очень легкий

Конфигурация немного затянута, но хорошо масштабируется: например, ключ ‘di’ в файле конфигурации модуля содержит все классы вместе с их параметрами внедрения. Полная структура стека приходит со случайной сложностью, которую мы должны принять, чтобы заимствовать все ее возможности.

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

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

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

Контроллеры могут быть очень легковесными по сравнению с Zend Framework 1: они могут указывать сеттеры для внедрения, вместо того, чтобы охотиться за объектами. Это не волшебная особенность: вы указываете их список в конфигурации, и это заставит вас задуматься о соавторах и их количестве. Но контроллер остается тонким и даже инстанцируемым в изоляции (теоретически).

Действия возвращают модель представления, так что они вообще не должны знать объект представления:

class AlbumController extends ActionController
{
    /**
     * @var \Album\Model\AlbumTable
     */
    protected $albumTable;

    public function indexAction()
    {
        return array(
            'albums' => $this->albumTable->fetchAll(),
        );
    }

    public function setAlbumTable(AlbumTable $albumTable)
    {
        $this->albumTable = $albumTable;
        return $this;
    }   
}

Сходства с 1.x

Некоторые соглашения и API являются подробными, как в Zend Framework 1, но это означает, что вам не придется изучать их снова:

• в контроллеру API «сек и его помощники: от контроллера у вас есть доступ к запросу, а также особенности смешанных в таком , как перенаправления.
• Формы позволяют определять элементы (с метками, проверкой и фильтрами) в подклассах, обеспечивающих init ().
• Представления соответствуют обычной структуре папок <controller> / <action> .phtml; помощники, такие как escape () и url (), доступны вместе с переменными представления $ this.

Базовая поддержка базы данных также присутствует с классами шлюза табличных данных и его производными. Конечно, вы можете интегрировать Doctrine2 или другие ORM по вашему выбору.

Выводы

Следующий вопрос — это elePHPant в комнате: почему я должен использовать Zend Framework 2 вместо Symfony 2? Этот анализ показал, что у ZF2 более простой путь обновления кода приложений Zend Framework 1 и приобретенных вами ноу-хау. Кроме того, он не менее современен, чем Symfony, по своему дизайну, несмотря на то, что он является портом, а не полностью переписан.