Где разместить логику в Symfony 3 приложении (+ Doctrine 2)?

Question

[You Care]

Всем привет, может кто посоветует где правильней/лучше разместить логику когда есть несколько сущностей (Doctrine entity) которые имплеменируют общий интерфейс?
Ситуация такая, есть интерфейс Request:

<?php

namespace AppBundle\Entity;

interface Request
    public function approve();
    public function reject();
}

и несколько сущьностей: Invite и JoinRequest в первом компания приглашает человека в компанию, во втором наоборот.

Пример Invite:

<?php

namespace AppBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/** @ORM\Entity */
class Invite implements Request
{

    /**
     * @ORM\Column(type="integer") @ORM\Id @ORM\GeneratedValue
     * @var int
     */
    private $id;

    /**
     * @ORM\ManyToOne(targetEntity="Company")
     * @ORM\JoinColumn(nullable=false)
     * @var Company
     */
    private $company;

    /**
     * @ORM\ManyToOne(targetEntity="User")
     * @ORM\JoinColumn(nullable=false)
     * @var User
     */
    private $user;

    public function approve()
    {
        // Some logic here. Add user to company, send mail, add flash message etc...
    }

    public function reject()
    {
        // Same
    }

    // Getters/Setters.
}

также будут и другие типы сущностей (запрос на обмен контактами и т.д.)
Насколько я понял размещать какую либо бизнес логику в самих Doctrine Entity считаеться плохой практикой да и передавать зависимости в Entity (mailer, twig templating, flash messages) выглядит не очень красиво, в контроллере тоже, так что единственное что мне приходит в голову это выделить под все эти Request Entity отдельный сервис, или даже свой под каждый, но не убивает ли это весь смысл полиморфизма?

Answer 1

[voronkovich]

Я бы выбрал 2-й вариант - под каждую сущность свой сервис реализующий логику. Не могли бы вы уточнить, что вы имеете ввиду во фразе "убивает смысл полиморфизма"? Полиморфизм не должен быть самоцелью. Предпочитая декорирование наследованию, вы ведь не убиваете смысл наследования?

Comments

[You Care]

Ну я имею ввиду если бы мы могли бы просто вызывать approve() на модели зная лишь её интерфейс, нам бы можно было бы не знать о том, что кроется за методом кажого конкретного класса, а так не совсем понятно зачем этот интерфейс вообще нужен, получается от него можно будет отказаться, хотя действия (отклонить, подтвердить) остаются общими у приглашения, запрос на добавление в компанию, запрос на обмен контактами, удаление фирмы и т.д.

[voronkovich]

koji6ac9h: Да, от интерфейса можно отказаться. Но логику в моделях лучше не размещать. Максимум, что бы я туда добавил - это поле state:

public function approve()
{
$this->state = self::APPROVED;
}

public function reject()
{
$this->state = self::REJECTED;
}

Также, можно вынести эти методы в трейт.

[You Care]

voronkovich: Ну у меня в принципе в живом коде (не в том, что я пощу здесь) точно это же и написано.
Просто жалко расставаться с интерфейсом, придётся везде if'ы и instanceof'ы размазывать, во вьюхах, в уведомлениях и т.д.

[You Care]

Или же оставить интерейс только с этим функционалом (смены состояния) и использовать как маркер

[voronkovich]

koji6ac9h: Тогда оставьте. Но лучше переименуйте его, Request - имя не очень подходящее. Я бы назвал его InviteInterface или как-то так.

[You Care]

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

[voronkovich]

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

Answer 2

[Myroslav Berlad]

Как вариант (если работать с анемичной моделью):

Контроллер:

class InviteController
{
    public function acceptCompanyInviteAction(Invite $invite)
    {
          /** просто как пример */
         $this->get('invite.manager')->acceptCompanyInvite($invite);

         return new Response('acccepted');
    }

Менеджер инвайта:

class InviteManager
{
    /** @var InviteRepository $repository */
    private $repository;

    /** @var EntityManagerInterface $entityManager */
    private $entityManager;

    public function __construct(EntityManagerInterface $entityManager)
    {
        $this->entityManager = $entityManager;
        $this->repository = $entityManager->getRepository('AppBundle:Invite'); 
    }
   
    public function acceptCompanyInvite(Invite $invite)
    {
         /** ваша логика  */
        
         $this->entityManager->persiste($invite);
         $this->entityManager->flush($invite);

         return $invite;
    }

Менеджер создается для абстрагирования от репозитория. Использовать репозиторий в контроллере както по мне не очень. У нас, как правило под каждую Entity есть свой репозиторий и менеджер. Структура каталогов в вашем случая у нас такая:

Entity
-----Repository
---------InviteRepository
-----Manager
---------InviteManger
-----Invite

Ну ето очень простой способ, не лучший но довольно акуратный.

А вообще, если есть время ознакомтесь с такими подходами: http://williamdurand.fr/2013/08/07/ddd-with-symfon... и https://jorgearco.com/ddd-with-symfony/ - вот репа последнего: https://github.com/jorge07/ddd-playground