Как в Symfony 2 вызвать Entity Manager в KnpMenu?

Question

[Quber]

Есть сервис реализующий Breadcrumbs с помощью KnpMenu

services:
    app.one:
        class: App\AdminBundle\Menu\BreadscampBuilder
        arguments:
            - ["@knp_menu.factory"]
    app.breadcrumb:
        class: Knp\Menu\MenuItem
        factory_service: app.one
        factory_method: createBreadcrumbMenu
        arguments: ["@request"]
        scope: request
        tags:
            - { name: knp_menu.menu, alias: breadcrumb }

И класс, отвечающий за его формирование:

namespace App\AdminBundle\Menu;

use Knp\Menu\FactoryInterface;
use Symfony\Component\HttpFoundation\Request;

class BreadscampBuilder
{
    private $factory;

    /**
     * @param FactoryInterface $factory
     */
    public function __construct(FactoryInterface $factory)
    {
        $this->factory = $factory;
    }

    public function createBreadcrumbMenu(Request $request)
    {
         // Как тут вызвать entityManager ?
     }

        return $menu;
    }
}

Как в данном классе вызвать Entity Manager?
На stackoverflow.com подсказывают добавить следущее:

protected $entityManager;

    public function __construct($entityManager)
    {
        $this->entityManager = $entityManager;
    }

И в сервисе добавить агрумент:

arguments:
    entityManager: "@doctrine.orm.entity_manager"

Но я не могу сообразить как добавить его в сервис при моём раскладе. Помогите пожалуйста.

Comments

[Quber]

Всем спасибо!! :)

Answer 1

[GHua]

Та что-ж такое, исправить не могу сообщение.

app.one:
        class: App\AdminBundle\Menu\BreadscampBuilder
        arguments:
             - ["@knp_menu.factory", @doctrine.orm.entity_manager]

Comments

[Quber]

ContextErrorException: Warning: Missing argument 2 for App\AdminBundle\Menu\BreadscampBuilder::__construct(), called in D:\OpenServer\domains\test.loc\app\cache\dev\appDevDebugProjectContainer.php on line 411 and defined in D:\OpenServer\domains\test.loc\src\App\AdminBundle\Menu\BreadscampBuilder.php line 15

[Quber]

namespace App\AdminBundle\Menu;

use Knp\Menu\FactoryInterface;
use Symfony\Component\HttpFoundation\Request;
use App\StaticBundle\Entity\Page;

class BreadscampBuilder
{
private $factory;
private $entityManager;

public function __construct(FactoryInterface $factory, $entityManager)
{
$this->factory = $factory;
$this->entityManager = $entityManager;
}

public function createBreadcrumbMenu(Request $request)
{
// Вызываем entity
}

return $menu;
}
}

[Quber]

@GHua спасибо
Исправленный вариант помог + добавил еще вот это
use Doctrine\ORM\EntityManager;

Answer 2

[Сергей Протько]

1) не завязывайте ваш этот breadcumbs-builder на entity manager, вы можете зарегистрировать нужный репозиторий для нужной вам энтити как сервис и работать с ним напрямую. Чем меньше ваш сервис знает о других сервисах тем лучше.

2) @GHua привел вам решение, которое должно работать (рекомендую еще тайпхинтинг применить для $entityManager так же как это сделано для $factory). Если оно у вас не работает - вы кэш чистили?

Comments

[Quber]

@Fesor ответил выше

[Quber]

@Fesor репозиторий это вы про сущность или про сервис, не понял

[GHua]

@Quber, репозиторий тоже можно определить как сервис. Это более эллегантный способ. @Fesor прав. Оба способа будут работать.

[Quber]

@GHua @Fesor А что вы имеете ввиду под репозиторием, можно ссылочку на мануал? Заранее спасибо.

[GHua]

symfony.com/doc/current/book/doctrine.html#custom-...

[Сергей Протько]

@Quber в идеале компоненты вашей системы, которые работают с данными ничего не должны знать о том, откуда эти данные берутся. Обычно создается сервис-репозиторий (он же возвращается если вызывать getRepository у entity manager), реализующий интерфейс (ваш интерфейс, что-то типа getLatestNewsFeed() или что там), который этот репозиторий имплементит. Другие же сервисы, которым нужны данные, завязываются только на этот интерфейс, а DIC все разрулит.

Этот способ не обязателен и вводит просто дополнительный уровень абстракции (ну и прививает чувство прекрастного, да и тестить сервисы проще). Зато в случае если в процессе жизни проекта придется менять логику хранения базы (переводить все на другую СУБД, или же частично переводить на всякие монги и коучдб), трудозатраты на это будут пропорциональны связанности системы. Именно по этому не рекомендуют использовать вызовы статических методов, сингелтоны и т.д., ибо вы завязываетесь на имени класса, а не потому что тестами сложно покрывать. Покрывать то сложно (сложнее чем без них) но можно, если захотеть. Но зачем?

[Quber]

@GHua Спасибо

[Quber]

@Fesor хм, интересно. Как то я этот момент упустил с репозиториями..

[Quber]

@Fesor Кажется я понял для чего это и как используется. Крутая вещь.. спасибо Вам большое!

[Quber]

@Fesor еще вопрос. Как правильно создавать и работать с репозиториями:
Одна сущность = один репозиторий
или
Одна сущность = несколько репозиториев (каждый под свою задачу)

[Сергей Протько]

одна сущьность - один репозиторий разумеется, у вас по другому и не получится сделать. Но вот интерфейсов оно может реализовывать много.

[Quber]

@Fesor можете показать пример сервис репозитория, интерфейс который он имплементит и описание сервиса в yml?
Заранее, спасибо.