Как организовать логику в Symfony с использованием наследования?

Question

[246]

Добрый день

Подскажите, пожалуйста, правильную организацию кода в симфони.
Ситуация, условно, такая: изначально создавалась сущность Order (заказ), и несколько экшенов в OrderController для создания, поиска и редактирования заказа. Соответственно, для каждого экшена были созданы свои формы (CreateOrderForm, и т.д.) и вьюхи (create_order.html.twig и т.д.). Так же создана OrderModel, в которой реализована вся логика обработки и сохранения в базу.
Теперь предстоит при наличии у заказа определенного атрибута реализовывать логику, частично отличную от изначальной (появляюся дополнительные поля для информации о заказе + некоторые отличия в обработке).
Для форм можно создать отдельные CreateNewOrderForm и т.д., которые отнаследовать от уже существующих. Вьюхи разбить отдельные шаблоны, вынести в файлы и для разных типов заказа отрисовывать соответстсующие. Для организации логики так же есть вариант создать NewOrderModel, которую отнаследовать от существующей и переопределеить нужные методы.

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

if ($orderType == 'new') {
   $form = $this->createForm(new CreateNewOrderForm());
} else {
   $form = $this->createForm(new CreateOrderForm());
}

и аналогичные блоки кода для вызова модели и отрисовки вьюх - как-то тоже попахивает нарушением принципов ООП. Тем более при появлении новых типов данный блок условий будет только разрастаться.

Какие есть более правильные варианты?

Comments

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

а чем отличаются принципиально NewOrder и Order? Тут проблема с именованием или это одно и то же?

Answer 1

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

Какие есть более правильные варианты?

проектируем нормально сущности в терминах бизнес логики (NewOrder как-то сильно звездными войнами попахивает).

Между формами и сущностями ходят DTO. Делаем сервисный слой и оставляем контроллеры тонкими. А еще можно CQRS и EventSourcing но чувствую ранова-то, хотя возможно так было бы даже проще.

Собственно никакой конкретики в вопросе нет. Вас смущает дублирование кода в контроллерах? выносите дублирование в приватные методы. Логики в контроллерах быть не должно, там только работа с формами и получание из них данных (по хорошему).

Comments

[246]

"проектируем нормально сущности в терминах бизнес логики (NewOrder как-то сильно звездными войнами попахивает)." - я упростил суть и постарался задать вопрос без лишних деталей. Само собой, в проекте названий типа NewOrder нет

"Между формами и сущностями ходят DTO. Делаем сервисный слой и оставляем контроллеры тонкими. А еще можно CQRS и EventSourcing но чувствую ранова-то, хотя возможно так было бы даже проще." - спасибо за общие советы, но вот как раз тут хотелось бы конкретики

"Вас смущает дублирование кода в контроллерах? выносите дублирование в приватные методы. Логики в контроллерах быть не должно, там только работа с формами и получание из них данных (по хорошему)." - даже для какого-нибудь создания заказа контроллер выглядит

$model = $this->getOrderModel();
$someDataForForm = $model->getSomeData();

$form = $form = $this->createForm(new CreateOrderForm($someDataForForm));

if ($request->getMethod() == 'POST') {
if ($form->isValid()) {
$data = $form->getData();
try {
$model->createOrder($data);
} catch (SomeException $e) {
...
} + еще несколько исключений
} else {
...
}
}

return $this->render('create_order.html.twig', array(...));

хотя на самом деле кода еще немного больше. Что тут выносить в отдельные приватные методы, если отличаться будут только три строки
$model = $this->getOrderModel();
$form = $form = $this->createForm(new CreateOrderForm());
$model->createOrder($data);
? Не очень красиво будет выглядеть. Писать для каждой из этих трех строк ifы - тоже не идеально. Вот хотел посоветоваться, как правильно поступают в подобных случаях