Лучшие практики в Symfony 2 — Создание проекта

Symfony 2 Best Practices

Приветствую вас дорогие мои читатели, с последнего моего поста утекло не мало воды, но время идет и все движется в перед как и я собственно не стою на месте и постоянно оттачиваю свое мастерство. Сегодня я хотел бы поделиться с вами весьма интересным в настоящее время для меня материалом, надеюсь для вас тоже, а именно моим достаточно вольным переводом первой главы из книги Symfony Best Practices.

Установка Symfony 2

Существует только один рекомендуемый способ установки Symfony 2:

Лучшая практика
Всегда используйте Composer для установки Symfony 2.

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

Управление зависимостями с Composer

Перед установкой Symfony 2, вы должны убедиться в том, что у вас глобально установлен Composer. Откройте терминал (называемый также консолью) и выполните следующую команду:

$ composer --version
Composer version 1e27ff5e22df81e3cd0cd36e5fdd4a3c5a031f4a 2014-08-11 15:46:48

Вы, вероятно, увидите другую версию Composer. Не берите это в голову, потому, что Composer обновляется на постоянной основе и его версия не имеет особого значения.

Установка Composer глобально

В случае, если у вас не установлен глобально Composer, то вам необходимо выполнить следующие команды в терминале Linux или Mac OS X (вторая команда попросит ввести пароль пользователя):

$ curl -sS https://getcomposer.org/installer | php
<p class="remark">$ sudo mv composer.phar /usr/local/bin/composer

В зависимости от вашего дистрибутива Linux, вам может потребоваться выполнить команду su вместо sudo

Если вы используете Windows, скачайте установочный пакет с страницы загрузки Composer и с помощью пошагового мастера установки установите его.

Создание приложения блога

Теперь, когда все настроено правильно, вы можете создать новый Symfony 2 проект. В вашем терминале, перейдите в каталог, где у вас есть права на создание файлов и выполните следующие команды:

$ cd projects/
$ composer create-project symfony/framework-standard-edition blog/

Эта команда создаст новый каталог с именем blog, который будет содержать новый проект на основе самой последней стабильной версии Symfony 2.

Проверка установки Symfony 2

После завершения установки, перейдите в каталог blog/ и для того, что бы убедиться, что Symfony 2 установлен правильно, выполните следующую команду:

$ cd blog/
$ php app/console --version

Symfony version 2.6.* - app/dev/debug

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

$ php app/check.php

В зависимости от вашей системы, при выполнении скрипта check.php вы можете увидеть до двух различных списков. Первый список отображает информацию об обязательных требованиях, которые ваша система должна удовлетворять, чтобы запускать приложения на базе Symfony 2. Второй список отображает дополнительные требования, необходимые для более оптимального выполнения приложений:

Symfony2 Requirements Checker
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> PHP is using the following php.ini file:
  /usr/local/zend/etc/php.ini

> Checking Symfony requirements:
  .....E.........................W.....

[ERROR]
Your system is not ready to run Symfony2 projects

Fix the following mandatory requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 * date.timezone setting must be set
   > Set the "date.timezone" setting in php.ini* (like Europe/Paris).

Optional recommendations to improve your setup
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 * short_open_tag should be disabled in php.ini
   > Set short_open_tag to off in php.ini*.

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

Структура приложения

После создания приложения, перейдите в каталог blog/, и вы увидите несколько файлов и каталогов, сгенерированных автоматически:

blog/
├─ app/
│  ├─ console
│  ├─ cache/
│  ├─ config/
│  ├─ logs/
│  └─ Resources/
├─ src/
│  └─ AppBundle/
├─ vendor/
└─ web/

Текущая иерархия фалов и директорий это рекомендуемая структура приложения для ваших проектов на базе Symfony 2. Рекомендованное назначение каждого из этих каталогов следующее:

app/cache/, хранит все файлы кэша, генерируемые приложением;
app/config/, хранит всю конфигурацию, определенную для любой среды выполнения;
app/logs/, хранит все файлы логов, создаваемые приложением;
app/Resources/, хранит все шаблоны и файлы переводов для приложения;
src/AppBundle/, хранит весь специфичный код для Symfony 2 (контроллеры и маршруты), ваш доменный код (например классы Doctrine 2) и всю бизнес логику вашего приложения;
vendor/, это каталог куда Composer устанавливает все зависимости вашего приложения и вы ни когда не должны изменять его содержимое вручную;
web/, хранит все файлы фронт контроллера и все статические ресурсы приложения такие как таблицы стилей, JavaScript файлы и изображения.

Бандлы приложения

Когда фреймворк Symfony 2.0 был выпущен, большинство разработчиков для разделения приложения на логические модули применили подход из Symfony 1.x. Именно поэтому большинство приложений на Symfony 2 для разделения кода на логические модули используют бандлы, например: UserBundle, ProductBundle, InvoiceBundle и т.д.

Но подразумевается, что бандл это то, что будет повторно использоваться как отдельная независимая часть приложения. Если UserBundle не может использоваться «как есть» в другом приложении на Symfony 2, то он не может быть самостоятельным бандлом. Кроме того InvoiceBundle зависит от ProductBundle, то нет ни какой пользы от использования двух отдельных бандлов.

Лучшая практика
Создавайте только один бандл с именем AppBundle для всей бизнес логики вашего приложения

Реализация единственного бандла с именем AppBundle в ваших проектах сделает ваш код более кратким и понятным. Начиная с Symfony 2.6, официальная документация Symfony 2 использует имя AppBundle.

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

Подводя итог изложенному выше ниже представлена типичная структура приложения на базе Symfony 2, которое следует лучшим практикам:

blog/
├─ app/
│  ├─ console
│  ├─ cache/
│  ├─ config/
│  ├─ logs/
│  └─ Resources/
├─ src/
│  └─ AppBundle/
├─ vendor/
└─ web/
   ├─ app.php
   └─ app_dev.php

Если вы используете Symfony 2.6 или более новую версию, то AppBundle бандл уже сгенерирован для вас. Если вы используете более старую версию Symfony 2, то вы можете сгенерировать его в ручную следующей командой:

$ php app/console generate:bundle --namespace=AppBundle --dir=src --format=annotation --no-interaction

Изменение структуры каталогов

Если ваш проект или инфраструктура требует некоторых изменений в структуре каталогов используемой по умолчанию для приложений на Symfony 2, то можно переопределить местоположение основных каталогов: cache/, logs/ and web/.

Кроме того, когда выйдет Symfony 3, то будет использоваться несколько иная структура каталогов:

blog-symfony3/
├─ app/
│  ├─ config/
│  └─ Resources/
├─ bin/
│  └─ console
├─ src/
├─ var/
│  ├─ cache/
│  └─ logs/
├─ vendor/
└─ web/

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

Оригинал