Создание проекта

Создание проекта

Установка Symfony

В прошлом, проекты Symfony создавались с помощью Composer, менеджера зависимостей для PHP-приложений. Однако, текущей рекомендацией является использование установщика Symfony, который должен быть установлен до создания вашего первого проекта.

Best Practice

Используйте установщик Symfony, чтобы создать новые проекты, основанные на Symfony.

Прочтите статью Installing & Setting up the Symfony Framework, чтобы узнать, как устаналивать и использовать установщик Symfony.

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

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

1
2
3
4
5
6
$ cd projects/
$ symfony new blog

# Windows
c:\> cd projects/
c:\projects\> php symfony new blog

Note

Если установщик для вас не работает или ничего не выводит, убедитесь в том, что на вашем компьютере установлено и включено расширение Phar.

Эта команда создаёт новый каталог под названием blog, который содержит новый свежий проект, основанный на наиболее новой стабильной доступной версии Symfony. Кроме того, установщик проверяет, соответствует ли ваша система техническим требованиям, необходимым для выполнения приложений Symfony. Если нет, то вы увидите список изменений, необходимый для соответствия требованиям.

Tip

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

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
blog/
├─ app/
│  ├─ config/
│  └─ Resources/
├─ bin
│  └─ console
├─ src/
│  └─ AppBundle/
├─ var/
│  ├─ cache/
│  ├─ logs/
│  └─ sessions/
├─ tests/
│  └─ AppBundle/
├─ vendor/
└─ web/

Эта иерархия файлов и каталогов является соглашением, предложенным Symfony для структурирования ваших приложений. Рекомендуемая цель каждого каталога следующая:

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

Пакеты приложения

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

Но пакет должен быть чем-то, что может быть использовано повторно в качестве отдельной части ПО. Если UserBundle не может быть использован "сам по себе" в других приложениях Symfony, то он не должен быть собственным пакетом. Более того, если InvoiceBundle зависит от ProductBundle, то преимущества в содержании двух отдельных пакетов нет.

Best Practice

Создайте только один пакет под названием AppBundle для логики вашего приложения.

Реализация единого пакета AppBundle в ваших проектах сделает ваш код более компактным и лёгким для понимания.

Note

Нет необходимости в добавлении префикса вашего поставщика к AppBundle (например, AcmeAppBundle), так как этот пакет приложения никогда не будет распространяться.

Note

Другая причина создать новый пакет - это когда вы переопределяете что-то в пакете поставщика (например, контроллер). См. How to Use Bundle Inheritance to Override Parts of a Bundle.

В конце-концов, это типичная структура каталогов приложения Symfony, следующего лучшим практикам:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
blog/
├─ app/
│  ├─ config/
│  └─ Resources/
├─ bin/
│  └─ console
├─ src/
│  └─ AppBundle/
├─ tests/
│  └─ AppBundle/
├─ var/
│  ├─ cache/
│  ├─ logs/
   └─ sessions/
├─ vendor/
└─ web/
   ├─ app.php
   └─ app_dev.php

Tip

Если ваша установка Symfony не поставляется с предварительно сгенерированным AppBundle, то вы можете сгенерировать его вручную, выполнив эту команду:

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

Расширение и структура каталога

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

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.