voronkovich

Под ваше описание подходит Service Subscriber

Что такое "подписчик сервисов"?

Это сервис, который получает свои зависимости в виде локатора (https://en.wikipedia.org/wiki/Service_locator_pattern). При этом, локатор реализует ленивую загрузку, что позволяет не создавать экземпляры сервисов без необходимости.

Когда его следует использовать?

Когда у сервиса много зависимостей, но не все они используются им одновременно.
Примером, может служить AbstractController, который зависит от Twig, Doctrine, Router и т.д.
Очевидно, что не для каждого запроса нужен Twig (json api), и не в каждом запросе есть обращение к БД.
См. https://github.com/symfony/symfony/blob/e1581a0937...

Как его создать?

Реализовать интерфейс ServiceSubscriber:

<?php

use Psr\Container\ContainerInterface;
use Symfony\Contracts\Service\ServiceSubscriberInterface;

class SomeService 
{
    public function __constructor(
        private ContainerInterface $container,
    ) {
    }
    
    public static function getSubscribedServices(): array
    {
        return [
            ServiceFirst::class => ServiceFirst::class,
            ServiceSecond::class => ServiceSecond::class,
            SomeCommonService::class => SomeCommonService::class,
        ];
    }
    
    public function methodFirst()
    {
        $this->container[SomeCommonService::class]->doSomethingCommon();
        $this->container[ServiceFirst::class]->doSomethingFirst();

        return $this->commonMethod();
    }
    
    public function methodSecond()
    {
        $this->container[SomeCommonService::class]->doSomethingCommon();
        $this->container[ServiceSecond::class]->doSomethingSecond();
        
        return $this->commonMethod();
    }

    private function commonMethod(): string
    {
        // some code
        
        return 'some string';
    }
}

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

Сборку фронтенда лучше делать локально. Я, например, обычно для таких вещей использую Ansible.

Приведу пример, как это могло бы выглядеть в виде shell-сценария (можете просто копировать и выполнять команды в командной строке шаг за шагом и смотреть что происходит):

#!/bin/sh

# Создание временной директории
cd "$(mktemp --directory)";

# Клонирование репозитория во временную директорию
git clone https://github.com/symfony/demo .;

# Извлечение ветки для релиза
git checkout master;

# Установка зависимостей фронтенда
npm install

# Сборка фронтенда
node_modules/.bin/encore production

# Загрузка кода из временной директории на сервер при помощи rsync

# Остальные действия производятся уже на сервере

Я повторил ваши шаги на чистой установке. Всё работает нормально.

1. Попробуйте очистить кэш: rm -rf var/cache.

2. В Symfony есть несколько команд для отладки подобных ошибок:

$ bin/console debug:config

$ bin/console debug:config gesdinet_jwt_refresh_token

Посмотрите, что они выведут.

На мой взгляд их лучше не использовать вообще.

1. Эта идея была взята из Hibernate. Но, Java позволяет в последствии сделать дозагрузку данных которые не были загружены изначально. Т.е. использование partial objects не может привести к ошибке. В PHP у объектов нет API аналогичного Java. У меня есть подозрение, что именно поэтому partial objects будут убраны из Doctrine 3, как это стало с поддержой операций detach/merge.

2. Реализация partial objects в Doctrine противоречит принципу "Модель всегда должна быть валидна"

Кстати, вы забыли про вариант с использование легковесного DTO (см. паттерн Flyweight), вместо массивов. См. https://www.doctrine-project.org/projects/doctrine...

Когда можно использовать массивы?

Массивы легко сериализуются, например, с ними можно быстро сделать API:

public function api(EntityManagerInterface $entityManager): Response
{
    $posts = $entityManager->createQuery('SELECT p FROM App\Entity\Post p')->getArrayResult();

    return new JsonResponse($posts);
}

Вам нужно создать расширение для Twig и реализовать функцию там. См. https://twig.symfony.com/doc/2.x/advanced.html#id2

Попробую привести очень примитивный пример. Допустим, мы делаем простое приложение для микроблоггинга. Каждая сущность будет иметь вид:

class Tweet
{
    private $id;
    private $content;

    public function __construct(int $id, string $content)
    {
        $this->id = $id;
        $this->content = $content;
    }

    public function getId(): int
    {
        return $this->id;
    }

    public function getContent(): string
    {
        return $this->content;
    }

    public function setContent(string $content): void
    {
        $this->content = $content;
    }
}

Схема данных:

CREATE TABLE tweets (
    id INTEGER PRIMARY KEY,
    content VARCHAR(255) NOT NULL
)

Следующая реализация UnitOfWork будет иметь несколько ограничений:

1. Она умеет работать только с Tweet;
   
2. Она умеет только загружать сущности и сохранять произведённые в них изменения.
   

class UnitOfWork
{
    private $connection;
    private $identityMap;
    private $data;

    public function __construct(\PDO $connection)
    {
        $this->connection = $connection;
        $this->identityMap = [];
        $this->data = [];
    }

    public function find(int $id): Tweet
    {
        if (isset($this->identityMap[$id])) {
            return $this->identityMap[$id];
        }

        $query = $this->connection->prepare('SELECT * FROM tweets WHERE id = ?');
        $query->execute([ $id ]);

        if (false === $data = $query->fetch()) {
            throw new \Exception(\sprintf('Tweet with id "%d" not found.', $id));
        }

        $id = (int) $data['id'];

        // Исходные данные сохраняются для того, чтобы в дальнейшем вычислить изменения.
        $this->data[$id] = $data;

        $tweet = new Tweet($id, $data['content']);

        $this->identityMap[$id] = $tweet;

        return $tweet;
    }

    public function commit(): void
    {
        // Вообще говоря, лучше вычислить все изиенения, создать один "большой" запрос
        // и выполнить его внутри транзакции, но для простоты мы сделаем для каждого
        // изменения отдельный запрос
        $query = $this->connection->prepare('UPDATE tweets SET content = ? WHERE id = ?');
        foreach ($this->identityMap as $tweet) {
            if ($tweet->getContent() !== $this->data[$tweet->getId()]['content']) {
                $query->execute([ $tweet->getContent(), $tweet->getId() ]);
            }
        }
    }
}

Полный пример можете скачить и посмотреть тут: https://gist.github.com/voronkovich/d35cdcdf6eb09e...

Оба способа правильные. Просто второй более устойчив к CSRF-атакам. Например, компонет форм по умолчанию использует имя класса формы для поля "intention" ("ключевое слово", если использовать ваше определение): https://github.com/symfony/form/blob/a0386553fabb5...

С другой стороны, есть мнение, что использование различных токенов, не делает приложение более безопасным. См. https://github.com/symfony/symfony/issues/18115

Лично я использую первый вариант т.е. один токен на все приложение.

Вы запрос неправильно составляете. Должно быть примерно так (полагаю, у вас сконфигурирована связь @ManyToOne между Employee и Department):

SELECT MAX(employee.salary)
FROM AppBundle:Employee employee
JOIN employee.department department
WHERE department.id = :id

Можно сделать без доп. соединения, если использовать DQL-функцию IDENTITY:

SELECT MAX(employee.salary)
FROM AppBundle:Employee employee
WHERE IDENTITY(employee.department) = :id

Попробуйте так:

$client = self::createClient();

$client->setServerParameter('HTTP_HOST', 'symfony-test');

Я бы использовал оба способа одновременно:

• Указывать значение по умолчанию в сущности необходимо, т.к. сущность всегда должна быть валидна;
  
• Указывать значение по умолчанию для столбца тоже необходимо, т.к. бывают случаи когда приходится работать с "голым" SQL.
  

<?php

namespace App\Entity;

/**
 * @Entity
 */
class User
{
    const DEFAULT_ROLE = 'user';

    /**
     * @Column(type="string", options={"default": User::DEFAULT_ROLE})
     *
     * @var string
     */
    private $role = self::DEFAULT_ROLE;
}

В простейшем случае, вы можете вынести обработку OPTIONS в отдельный метод:

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

/**
 * @Route("/blog")
 */
class BlogController extends AbstractController
{
    /**
     * @Route("/", methods="OPTIONS")
     */
    public function options(Request $request): Response
    {
        $response = new Response();

        $response->headers->set('Access-Control-Allow-Methods', 'OPTIONS, GET');

        return $response;
    }

    /**
     * @Route("/", methods="GET", name="blog_index")
     */
    public function index(Request $request): Response
    {
        return $this->json([
            'message' => 'hello',
        ]);
    }
}

1. Создаете директорию для бандлов (например, bundles как предлагает Максим Федоров)

2. Создаете директорию бандла. Например, bundles/AcmeBundle

3. В composer.json добавляете:

"autoload": {
    "psr-4": {
        "App\\": "src/",
        "AcmeBundle\\": "bundles/AcmeBundle/"
    },
}

4. В директории бандла создаете его класс:

<?php

namespace AcmeBundle;

use Symfony\Component\HttpKernel\Bundle\Bundle;

class AcmeBundle extends Bundle
{
}

5. Регистрируете бандл в файле config/bundles.php:

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    AcmeBundle\AcmeBundle::class => ['all' => true],
];

Параметры не сработают. Контейнер и роутер ничего не знают друг о друге. В Symfony вся магия сделана в FrameworkBundle: https://github.com/symfony/framework-bundle/blob/8...

Symfony 4 - это микрофреймворк, лучше используйте его, а не собирайте собственный:

$ composer create-project symfony/skeleton

Также, вы можете передать в FileLocator несколько путей:

$fileLocator = new FileLocator([ __DIR__, __DIR__.'/../../app' ]);

См. https://api.symfony.com/4.0/Symfony/Component/Conf...