Не надо называть из хендлерами.
Если брать пример $result = ['my_data' => $var];
То не надо конечно. Но я понимаю о чем вы. Хотя если оперировать объектами в полной мере, то можно создать что то типа responseMyData
Контроллер принимает реквест и отдает респонс, вызывая хендлр. Больше в нем не должно быть и строчки кода.
За исключением каких то индивидуальных реализаций. Вот пример моих контроллеров. Убрал под
Код котроллера - спойлер<?php
class orderController extends AbstractController {
/**
* @ApiDoc(
* section="travelSystem",
* input=OrderRequest::class,
* statusCodes={
* 200="sucess",
* 404="Order not found"
* },
* views={"night_build"}
* )
* @RestDoc(
* security={Access::ORDER}
* )
*
* @return Response
*/
public function orderAction(OrderRequest $orderRequest): Response
{
// Команда - простой объект с геттерами
$command = new orderCommand(
$orderRequest->getHotel(),
$orderRequest->getCheckIn()
);
// Хендлер - в котором как раз и происходят все
// нужные нам операции по обработке
$this->get('commandBus')->handle($command);
return $this->responseForRest();
}
}
Как вы видите, тут имеются свои особенности, но котроллер тоненький.
Что же происходит в текущем хендлере?
Там проверяется существование дублирующих записей (а это вызов репы и условие), далее вызывается модель для order, которая получает команды и уходит на запись. Это приходится дублировать, т.к. код по сути индивидуальный для каждого обработчика но схож по функционалу.
А вот после записи в БД, вызывается слушатель, который вызывает событие на запись логов.
Данная операция нужна везде и поэтому вынесена в отдельный объект который может быть вызван в любом хендлере, путем DI конструктора
Далее еще хуже =) В логах имеется свой хендлер и своя цепочка событий.
Допустим мы делаем запись чего в блог, отправляем в хендлер нашу команду или что там может быть в laravel, где происходит обработка. В обработке может быть запись в БД а так же загрузка изображения.
Вот загрузку изображения, стоит выделить в отдельный сервис.
