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);
}

Оба способа правильные. Просто второй более устойчив к 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...