Управление состоянием с помощью Workflow
Управление состоянием с помощью Workflow
Наличие какого-либо состояния у модели — довольно обычное явление. Состояние комментария определяет только антиспам-сервис. Но что, если в будущем у вас появятся больше факторов для изменения состояния?
Возможно, вы захотите дать администратору сайта возможность модерировать все комментарии после того, как они будут проверены антиспам-сервисом. Вот как будет выглядеть этот процесс:
- Начинаем с состояния
submitted, когда пользователь отправляет комментарий; - Делегируем антиспам-сервису проанализировать комментарий и переключим его в зависимости от результата в одно из состояний:
potential_spam,hamилиrejected; - Если комментарий не был отклонён (то есть он не спам), ожидаем, пока администратор не решит, достаточно ли комментарий хорош, изменив его состояние на
publishedилиrejected.
Реализация данной логики — не слишком сложная задача. Однако добавление дополнительных правил значительно усложнит эту задачу. Воспользуемся Symfony-компонентом Workflow, чтобы не писать самим логику с нуля:
1
$ symfony composer req workflowОпределение бизнес-процессов
Бизнес-процесс комментария можно описать в конфигурационном файле config/packages/workflow.yaml:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
framework:
workflows:
comment:
type: state_machine
audit_trail:
enabled: "%kernel.debug%"
marking_store:
type: 'method'
property: 'state'
supports:
- App\Entity\Comment
initial_marking: submitted
places:
- submitted
- ham
- potential_spam
- spam
- rejected
- published
transitions:
accept:
from: submitted
to: ham
might_be_spam:
from: submitted
to: potential_spam
reject_spam:
from: submitted
to: spam
publish:
from: potential_spam
to: published
reject:
from: potential_spam
to: rejected
publish_ham:
from: ham
to: published
reject_ham:
from: ham
to: rejectedЧтобы убедиться в правильности построения этого бизнес-процесса, давайте отобразим его визуально:
1
$ symfony console workflow:dump comment | dot -Tpng -o workflow.png
Note
Команда dot является частью утилиты Graphviz.
Использование бизнес-процессов
Замените текущую логику в обработчике сообщений на новую с использованием определенного ранее бизнес-процесса:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
--- a/src/MessageHandler/CommentMessageHandler.php
+++ b/src/MessageHandler/CommentMessageHandler.php
@@ -6,19 +6,28 @@ use App\Message\CommentMessage;
use App\Repository\CommentRepository;
use App\SpamChecker;
use Doctrine\ORM\EntityManagerInterface;
+use Psr\Log\LoggerInterface;
use Symfony\Component\Messenger\Handler\MessageHandlerInterface;
+use Symfony\Component\Messenger\MessageBusInterface;
+use Symfony\Component\Workflow\WorkflowInterface;
class CommentMessageHandler implements MessageHandlerInterface
{
private $spamChecker;
private $entityManager;
private $commentRepository;
+ private $bus;
+ private $workflow;
+ private $logger;
- public function __construct(EntityManagerInterface $entityManager, SpamChecker $spamChecker, CommentRepository $commentRepository)
+ public function __construct(EntityManagerInterface $entityManager, SpamChecker $spamChecker, CommentRepository $commentRepository, MessageBusInterface $bus, WorkflowInterface $commentStateMachine, LoggerInterface $logger = null)
{
$this->entityManager = $entityManager;
$this->spamChecker = $spamChecker;
$this->commentRepository = $commentRepository;
+ $this->bus = $bus;
+ $this->workflow = $commentStateMachine;
+ $this->logger = $logger;
}
public function __invoke(CommentMessage $message)
@@ -28,12 +37,21 @@ class CommentMessageHandler implements MessageHandlerInterface
return;
}
- if (2 === $this->spamChecker->getSpamScore($comment, $message->getContext())) {
- $comment->setState('spam');
- } else {
- $comment->setState('published');
- }
- $this->entityManager->flush();
+ if ($this->workflow->can($comment, 'accept')) {
+ $score = $this->spamChecker->getSpamScore($comment, $message->getContext());
+ $transition = 'accept';
+ if (2 === $score) {
+ $transition = 'reject_spam';
+ } elseif (1 === $score) {
+ $transition = 'might_be_spam';
+ }
+ $this->workflow->apply($comment, $transition);
+ $this->entityManager->flush();
+
+ $this->bus->dispatch($message);
+ } elseif ($this->logger) {
+ $this->logger->debug('Dropping comment message', ['comment' => $comment->getId(), 'state' => $comment->getState()]);
+ }
}
}Новая логика выглядит следующим образом:
- Если комментарий может перейти в состояние
accept, значит проверяем сообщение на спам; - В зависимости от результата проверки, нужно выбрать подходящий переход;
- Вызываем метод
apply(), чтобы обновить состояние для объекта Comment, который в свою очередь вызывает в этом объекте методsetState(); - Сохраняем данные в базе данных, используя метод
flush(); - Повторно отправляем сообщение на шину, чтобы ещё раз запустить бизнес-процесс комментария для определения следующего перехода.
Так как ещё не реализована возможность проверки сообщения администратором, при следующий обработке сообщения в лог запишется следующее: "Dropping comment message".
Перед тем как начать следующую главу, давайте добавим автоматическую проверку:
1 2 3 4 5 6 7 8 9 10 11 12
--- a/src/MessageHandler/CommentMessageHandler.php
+++ b/src/MessageHandler/CommentMessageHandler.php
@@ -50,6 +50,9 @@ class CommentMessageHandler implements MessageHandlerInterface
$this->entityManager->flush();
$this->bus->dispatch($message);
+ } elseif ($this->workflow->can($comment, 'publish') || $this->workflow->can($comment, 'publish_ham')) {
+ $this->workflow->apply($comment, $this->workflow->can($comment, 'publish') ? 'publish' : 'publish_ham');
+ $this->entityManager->flush();
} elseif ($this->logger) {
$this->logger->debug('Dropping comment message', ['comment' => $comment->getId(), 'state' => $comment->getState()]);
}Выполните команду symfony server:log и добавьте комментарий к любой конференции, чтобы увидеть в терминале, как один за другим происходят переходы состояний.
Поиск сервисов из контейнера внедрения зависимостей
При использовании внедрения зависимостей мы получаем сервисы из контейнера, указывая имя интерфейса или конкретную реализацию класса. При нескольких реализациях одного и того же интерфейса, Symfony не сможет понять, какая из них вам нужна. В этом случае нужно более точно указать, что именно вы хотите получить.
В предыдущем разделе при внедрении WorkflowInterface мы как раз столкнулись с такой проблемой.
Как Symfony определяет, какую реализацию общего интерфейса WorkflowInterface нужно использовать при его внедрении через конструктор? На помощь приходит имя аргумента $commentStateMachine, которое должно состоять из названия бизнес-процесса (comment) и его типа (state_machine). Если имя аргумента не будет соответствовать данному именованию, вы получите ошибку.
Если вы не можете вспомнить, какое должно быть правильное имя аргумента, то попробуйте воспользоваться командой debug:container. Выполните следующую команду, чтобы получить список сервисов, в имени которых содержится "workflow":
1 2 3 4 5 6 7 8 9 10 11 12 13 14
$ symfony console debug:container workflow
Select one of the following services to display its information:
[0] console.command.workflow_dump
[1] workflow.abstract
[2] workflow.marking_store.method
[3] workflow.registry
[4] workflow.security.expression_language
[5] workflow.twig_extension
[6] monolog.logger.workflow
[7] Symfony\Component\Workflow\Registry
[8] Symfony\Component\Workflow\WorkflowInterface $commentStateMachine
[9] Psr\Log\LoggerInterface $workflowLogger
>Обратите внимание на вариант под номером 8, который говорит о том, что при внедрении интерфейса Symfony\Component\Workflow\WorkflowInterface нужно использовать имя аргумента $commentStateMachine.
Note
Можно воспользоваться командой debug:autowiring из предыдущей главы:
1
$ symfony console debug:autowiring workflow