Как организовать код в laravel?

Question

[Александр Панков]

Подскажите, как организовать "архитектуру".
1) у меня есть заказ (order->item->prоduct), те модель order, связана моделью item(это корзина заказа(товар в корзине)), а элемент корзины связан с моделью prоduct (товар каталога)
2) модель item хранит цену и количество купленного товара из каталога(prоduct) в заказе(order)
3) есть форма, где клиент может менять параметры товара в заказе(item), например прибавить количество или изменить цену
4) при отправке этой формы я просто (в одну строку) меняю данные в бд $item->update($request->only(['price', 'quantity'.....]) все это одна строка контроллера

5) ТЕПЕРЬ ВОПРОС, после смены, например количества, мне нужно пересчитать некоторые параметры заказа, например параметр "общая сумма" или "сумма доставки" или "статус заказа" и тп, не суть, суть в том, что в контроллере, который отвечает за смену товара в корзине, я вдруг начинаю работать с заказом и его параметрами - это не по GRAPS, SOLID (единственная ответственность, инфорамационный эксперт), какой путь (паттерн) выбрать, в контексте ларавела?

есть обсерверы, есть евенты и слушатели, есть "сервисный слой" (что бы это не значило)...
голова кругом

подскажите как бы вы сделали, где и как мне пересчитывать сам заказ, после смены его списка товаров?

у меня в голове
1) создаю сервис класс
2) инициализирую его в конструкторе контроллера
3) в методе контроллера одной строкой меняю данные корзины
4) тут же ниже дергаю метод сервиса "обновить заказ"

но с другой стороны, другому программисту ничего не мешает взять обновить данные корзины
и все, не пересчитывать заказ... как обезопаситься от этого?

как лучше (правильнее) сделать?

Answer 1

[vism]

подскажите как бы вы сделали, где и как мне пересчитывать сам заказ, после смены его списка товаров?

у меня в голове
1) создаю сервис класс
2) инициалиирую его в конструкторе контроллера
3) в методе контроллера одной строкой меняю данные корзины
4) тут же ниже дергаю метод сервиса "обновить заказ"
но с другой стороны, другому программисту ничего не мешает взять обновить данные корзины
и все, не пересчитывать заказ... как обезопаситься от этого?

Вот чес слово, светлая голова! думаешь о другом программисте.
А всё просто, не надо в контроллере обновлять.
Сделай сервис класс, где будут методы обновления и перерасчёта.
И прямо там это делай.
Т.е. метод обновить данные корзины, в котором будет обновление и вызов метода этого же класса для перерасчёта заказа.
И не забудь всё это в одну транзакцию обернуть.

А дальше лирика уже...

но с другой стороны, другому программисту ничего не мешает взять обновить данные корзины

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

И самое главное, бизнес будет тебя просить как ты щас делаешь с риском что кто-то сделает баг и потом пофиксить его, чем делать всё по канонам в 10-30 раз дольше, дороже и увеличия очень сильно вход для программситов. Ну а баги там тоже будут, только намного более сложные и трудноловимые.
За мои 12 лет я понял, что надо делать как хочет бизнес, а это максимально простой, понятный код и иногда фиксить баги. И ВСЕГДА вычищать технический долг.

Comments

[Александр Панков]

Спасибо за совет, идею понял

[vism]

Александр Панков, обновил ответ, чтоб понятнее было:)

[vism]

Александр Панков, есть ещё вариант слушать событие saving в item модели и обновлять order при изменениях зависимых полей.

Честно говоря не знаю как бы я сделал, от ситуации зависит.
С одной стороны, надо чтоб эти две модели у тебя обновлялись в одной транзакции.
С другой стороны, если прописать вызов метода сервиса для обновления order из события, ты обезопасишь себя (но и то не на 100%, всегда фрилансер самоучка может обновить БД напрямую, без сохранения через модель)

[Александр Панков]

vism ,

сложные тру структуры кода

Это вы про доктрину?

[vism]

Александр Панков, я про всё вместе, доктрина там одна из частей:)

Answer 2

[Дмитрий Гординский]

В альтернативу ответу который уже отмечен верным предложу вариант с Rich Domain Model.

Работайте не с отдельным Item, а с целым заказом.
Добавьте в сущность заказа метод changeItemQuantity(Item $item, integer $quantity)
И в нем помимо смены количества в том числе производите пересчет всего заказа.

Comments

[vism]

дык вроде и я об этом же:) только сущность заказа в ларавель это Модель )))
Поэтому нужно создавать сервис класс, а в нём вот этот метод, да:)

Answer 3

[pLavrenov]

1) Зачем хранить высчитанную сумму если ее можно посчитать на моменте выдачи
2) но с другой стороны, другому программисту ничего не мешает взять обновить данные корзины
и все, не пересчитывать заказ... как обезопаситься от этого?

Ты правильно думаешь в сторону разделения ответственности. Но все эти словечки блаблабла солид блаблаба другое. Рассуждай логически. Твое дело обновить данные в базе. Если тебе надо что-то пересчитать или сменить статус для этого есть эвенты.

Обсервер - это всего лишь отдельный класс который делается чтобы вынести из модели логику. При каждой манипуляции с моделью Laravel вызывает событие. Обсервер это как обработчик этих событий вынесенный в отдельный файл. У обсервера есть 2 метода (для примера только 2) - update и updated первый выполняется до сохранения в базу второй после. Обычно в этих методах вызывают другие эвенты и потом на них подписываются но это пока не в данной ситуации. Так вот в методе update можно сделать например обработку сумму перед добавлением в базу, а в updated смену статуса у заказа. Это в общем. Попробуй там ничего сложного.

Comments

[Александр Панков]

pLavrenov

Похоже что да,
Мне нужно создать обсервер, в нужных событиях триггерить евенты, а в листенерах уже вызывать метод сервиса по перерасчету полей.

Observer - Event - Listener - Service

Именно такой подход убережёт от «случайных перерасчётов» в обход «бизнеса» и логика будет разделена.

Пс: понимаю, что всегда можно сделать сырой звпрос к бд, все там поменять и никаких пакетов не будет тогда выполнено

[Александр Панков]

Выглядит как-то сложно, не знаю, как и писали выше, стоит ли оно того, не легче ли сразу вызвать в контроллере метод сервиса, внутри которого уже все и делать

[pLavrenov]

Александр Панков,

Мне нужно создать обсервер, в нужных событиях триггерить евенты, а в листенерах уже вызывать метод сервиса по перерасчету полей.

Да

---

Проще да. Только если понадобится сделать перерасчет из, например, команды. Как переиспользовать? Можно например из репозитория обновлять данные тогда вызов перерасчета будет только в методе репозитория, а на обновление всегда использовать этот метод. Но если надо сделать не только перерасчет. Будет 3-5-10 функций последовательных. С ивентами проще добавляй сколько надо, обрабатывай то что надо даже если это не связано с обработкой самой задачи.