Symfony 4 - новейшая версия одного из самых известных фреймворков PHP.
Она была выпущена 30 ноября 2017 года и пользуется большим успехом!
Одна из Самым большим отличием от старых версий является наличие очень маленьких зависимостей, устанавливаемых при запуске вашего проекта Symfony 4.
Symfony 4 настолько крошечный, что проект Silex был отклонен.

Как установить Symfony 4

Чтобы создать новое приложение Symfony 4, у вас должен быть установлен PHP 7.1 или выше и Composer.
С установленным Composer вы можете создать проект, запустив эту команду в вашу консоль:

composer create-project symfony/website-skeleton my-project

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

composer create-project symfony/skeleton my-project

В этой версии нет пакетов, поэтому она меньше.

Структура каталогов

Symfony 4 немного изменил свою структуру каталогов в соответствии с другими фреймворками и запросами сообщества, поэтому теперь новая структура каталогов выглядит так:

app /
Конфигурация приложения, шаблоны и переводы, в которых вы можете найти файл AppKernel, главную точку входа в конфигурацию приложения.

bin /
Исполняемые файлы (например, bin / console).

src /
PHP-код проекта, в котором у вас есть контроллеры, представления и каталоги сущностей.
В этой папке нет основного пакета, потому что идея Symfony 4 состоит в том, чтобы иметь один проект вместо нескольких пакетов в проекте.

tests /
Автоматические тесты (например, модульные тесты с PHPUnit или Behat или другими).

var /
Сгенерированные файлы (кеш, журналы и т. д.).

vendor /
Внешние библиотеки, установленные композитором.

public /
Корневой веб-каталог, в котором хранятся общедоступные и статические файлы, такие как изображения, таблицы стилей и файлы JavaScript. Эта папка является старой «веб-папкой».

Переменные среды

При разработке вашей системы вы можете захотеть иметь разные переменные, которые могут отличаться от других сред.
В предыдущих версиях Symfony вы помещали эти переменные в файл с именем parameters.yml и в parameters.yml.yourenv. Теперь этого файла не существует (вы, очевидно, можете изменить свой код, чтобы использовать его, но он немного сложен), и вам нужно записать эти переменные в файл с именем .env в корне проекта.
Очевидно, вы можете иметь разные файлы .env, но это зависит от того, сколько сред в вашем приложении.
Вот простой файл .env:

DB_USER=root
DB_PASS=pass

Вы также можете использовать внутри него такие переменные:

DB_USER=root
DB_PASS=${DB_USER}pass

Компонент, который читает эти файлы, - это компонент Dotenv, который анализирует файлы .env, чтобы сделать хранимые в них переменные среды доступными через getenv (), $ _ENV или $ _SERVER.
Если вы этого не сделаете. он уже есть в вашем проекте, вы можете запустить эту команду, чтобы сформировать свой интерфейс командной строки для его использования:

composer require symfony/dotenv

Чтобы получить значение переменной среды, вы можете использовать этот синтаксис внутри своего кода:

$dbUser = getenv(‘DB_USER’);

Помните, что Symfony Dotenv никогда не перезаписывает существующие переменные среды.

Автоэлектромонтаж

Автоматическое подключение - одна из самых мощных функций Symfony 4 (вы можете использовать ее, начиная с версии Symfony 3.3).
Она позволяет вам управлять службами в контейнере с минимальной конфигурацией, без указания, для Например, все аргументы, которые должны быть переданы вашей службе (теперь также контроллеры являются службами!).
Итак, если у вас есть класс службы, в котором вам нужно передать в метод __construct некоторые другие службы, вам нужно только включить автоматическое подключение и Symfony сделает это за вас!

Пример:

namespace App\Service;
use App\Util\Bar;
use Psr\Log\LoggerInterface;
class Foo
{
    private $logger;
    public function __construct(LoggerInterface $logger)
    {
      $this->logger = $logger;
    }
}

В более старом методе вам нужно было сделать это в своем services.yml

app.foo:
   class: AppBundle\Services\Foo
   arguments: [‘@logger’]

В этой новой версии вы можете сделать так:

app.foo:
   class: AppBundle\Services\Foo
   public: true

Таким образом, вам нужно указать только public как true. Представьте, что у вас есть множество аргументов для объявления многих сервисов, таким образом вы сэкономите время!
По сути, сервисы не являются общедоступными, поэтому вам нужно сделать это правдой в services.yml, если вы хотите, таким образом:

services:
   _defaults:
      autowire: true
      autoconfigure: true
      public: true

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

services:
   _defaults:
       autowire: true
       autoconfigure: true
       public: true
App\Services\YourService:
   class: App\Services\YourService
   public: false

Таким образом, опция Autowire указывает Symfony автоматически вводить зависимости в ваши сервисы.
Параметр Autoconfigure указывает Symfony автоматически регистрировать ваши сервисы как команды, подписчики событий и т. Д.

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

public function index(LoggerInterface $logger) 
{
   $logger->info(‘This is a injected service!’);
   //code
}

В этом действии вы вводите LoggerInterface напрямую, и вам не нужно создавать его экземпляр внутри действия!

Flex и рецепты

Symfony Flex - это плагин Composer, который вызывается, когда вы запускаете команды require, update и remove composer.
Когда вы запускаете эти команды поиска flex внутри Symfony Flex, сервер принимает их, устанавливает его и настройте его для вас, если пакет там есть.
Сила Flex заключается в том, что вам не нужно просматривать файлы readme всех библиотек для настройки вашего пакета, поскольку есть рецепт, который сделает это за вас .
Вам не нужно добавлять новый пакет в AppKernel.php, потому что flex уже сделал это при его установке.
Если ваш пакет не существует, он использует стандартное поведение Composer.

Flex отслеживает установленные им рецепты в файле symfony.lock, который необходимо сохранить в вашем репозитории кода.
Рецепты хранятся в двух разных репозиториях github:

  • Рецепт - это тщательно подобранный список рецептов для высококачественных и обслуживаемых упаковок. Symfony Flex смотрит в этот репозиторий по умолчанию.
  • Recipes-Contrib содержит все рецепты, созданные сообществом. Все они гарантированно работают, но связанные с ними пакеты могут не поддерживаться. Symfony Flex игнорирует эти рецепты по умолчанию, но вы можете выполнить эту команду, чтобы начать использовать их в своем проекте:
composer config extra.symfony.allow-contrib true

Внутри этого сайта Symfony вы можете просмотреть полный список рецептов, где вы можете найти, как установить их в свой проект.
Иногда есть псевдоним, поэтому вы можете использовать его как этот, чтобы быть быстрее и запомнить команду Полегче:

composer require logger

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

Компонент Messenger

Компонент Messenger помогает приложениям отправлять и получать сообщения в / из других приложений или через очереди сообщений.
Чтобы установить компонент, вам необходимо запустить с консоли:

composer require symfony/messenger

Как это работает?

Отправитель сериализует и отправляет сообщение чему-либо. Например, это может быть брокер сообщений или сторонний API.
Шина отправляет сообщение.
Поведение шины определяется упорядоченным стеком промежуточного программного обеспечения.
Компонент поставляется с набором промежуточного программного обеспечения, которое вы можете использовать.

При использовании шины сообщений с Symfony's FrameworkBundle для вас настраивается следующее промежуточное программное обеспечение:

LoggingMiddleware (регистрирует обработку ваших сообщений)

SendMessageMiddleware (включает асинхронную обработку)

HandleMessageMiddleware (вызывает зарегистрированный дескриптор)

Как только сообщение отправлено на шину, оно будет обработано «обработчиком сообщений».
Обработчик сообщений - это вызываемый PHP (то есть функция или экземпляр класса), который будет выполнять необходимую обработку вашего сообщения. .
Чтобы отправлять и получать сообщения, вам необходимо настроить адаптер. Адаптер будет отвечать за связь с вашим брокером сообщений или третьими сторонами.
Затем получатель Receiver десериализует и пересылает сообщение обработчику (ам). Это может быть средство удаления очереди сообщений или конечная точка API.

Для получения дополнительной информации свяжитесь со мной или подпишитесь на меня:

Твиттер
GitHub