Поскольку я усвоил трудный путь, сущности не должны хранить никакой реальной логики, поскольку их использование заключается в хранении данных.
Кроме того, я читал, что контроллеры не должны иметь никакого «реального кода», но при необходимости устанавливать только несколько значений и указывать их на службы, которые фактически используются для работы . ( Обрезка жира с контроллеров ).
Я понимаю моменты, и хотя я новичок в Symfony, я знаю, что классы с кодом «для всех и вся» просто ужасно плохие практики (и контроллеры по всей Symfony Book и Symfony Cookbook действительно выглядят так). Легко создавать, невозможно поддерживать. И если вы столкнетесь с ситуацией, когда вам нужно отделить свой код, вам будет очень весело. Но я понимаю, так как эти книги ориентированы прежде всего на новичков.
Итак, как мне создать Entity Type Managers . Они вообще могут пойти?
Скажем, у меня есть объект Image . Мне нужен ImageManager для удаления, обновления, вызова эскизов для создания эскизов и т. Д. Где это место? Где он вообще находится в структуре каталогов? Он не может быть неотображаемым объектом, так как ему нужны услуги, инжектируемые в него.
В статье «Поваренная книга по лучшей практике» не упоминается ничего подобного .
Я не знаю, что для этого есть лучшая практика, но когда я это делаю, я всегда Path\To\MyBundle\Manager пространство имен Path\To\MyBundle\Manager . Единственный пример, который я смог найти в своем проекте стороннего поставщика, который делает то же самое, – это ElasticaBundle .
Главное, что вы определяете своего менеджера как услугу и вводите нужные вам зависимости. Постарайтесь, чтобы ваш менеджер зависел от интерфейсов, а не от фактических классов, чтобы упростить тестирование и упростить замену отдельных компонентов позже, если это необходимо.
Это также очень хорошая идея, чтобы ваш менеджер реализовал интерфейс, который определяет все его общедоступные методы, так как класс RepositoryManager делает в ElasticaBundle I, связанном с выше.
Вы можете взглянуть на то, как FOSUserBundle структурирует свой код.
У этого есть UserManager в FOSUserBundle/Model который делает вещи, которые не требуют каких-либо знаний о хранилище пользовательских объектов и другого UserManager в FOSUserBundle/Doctrine который расширяет первое и что делает вещи, которые требуют знания уровня хранения (он получает например, инъецированный EntityManager). FOSUserBundle/Doctrine/UserManager определяется как служба, которая может вызываться из контроллеров.
Приятная вещь в этой структуре заключается в том, что она делает тестирование очень простым. FOSUserBundle/Model/UserManager тесты для FOSUserBundle/Model/UserManager очень легкие и не требуют издевательств над доктриной. FOSUserBundle/Doctrine/UserManager тесты для FOSUserBundle/Doctrine/UserManager – это место, где вещи доктрины издеваются.