как лучше сделать

у меня в бизнес логике есть класс Заказ, также есть две пары вид-контроллер: Офис и Цех. У заказа есть состояния: «начат», «не начат», «отменен», «завершен». цех работает с материалами, поэтому у него есть еще один статус - «не хватает материал». он возникает, когда состояние заказа - «не начат», и при этом не хватает материал. а офису пофиг на материалы, у него в любом случае будет одно состояние - «не начат». как лучше организовать код?

1. сделать новый класс в бизнес логике ЗаказДляЦеха, в котором будут свои состояния
2. сделать в классе Заказ новое свойство - состояние для цеха. будет два свойства: «состояние» и «состояние для цеха»
3. отправить клиенту новое свойство - «выполним ли заказ». на фронтенде цеха если состояние заказа - «не начат», при этом он «не выполним», установить статус «не хватает материал». так код фронтенда получается менее изящным.
4. сменить подход

Если состояния заказа для цеха и для офиса - это две разные сущности, то и делать надо два разных свойства.

Так что я бы делал как в 2)

сделать новый класс в бизнес логике ЗаказДляЦеха, в котором будут свои состояния - потенциально это решение выглядит более юзабельным, как m2m таблица в БД с доп свойствами. У тебя там лежат айди закада, айди цеха. По-итогу, если хочешь проверить статус заказа делаешь Join и имеешь полную информацию

Dont Mind сказал(а):↑

сделать новый класс в бизнес логике ЗаказДляЦеха, в котором будут свои состояния - потенциально это решение выглядит более юзабельным, как m2m таблица в БД с доп свойствами. У тебя там лежат айди закада, айди цеха. По-итогу, если хочешь проверить статус заказа делаешь Join и имеешь полную информацию

Нажмите, чтобы раскрыть...

я реализовал вариант 2

Lancer.Rev.X сказал(а):↑

я реализовал вариант 2

Нажмите, чтобы раскрыть...

 

чуть больше на эту тему написал в ЛС, ибо так себе выстрелили в ногу на проекте. Тут стоит разделить програмную логику (как тебе удобнее использовать данные) и логику хранения данных (как их лучше хранить чтобы избежать проблем)