Здравствуйте, Terix, Вы писали:

T>У тебя был аргумент — почему не добавить к объекту методы, которые реализуют логику, которая ему принадлежит. Мой — сущности, которые ты вытаскиваешь из БД объектами не являются, поэтому твой аргумент тут не применим.

А сущность "заказ" — это тоже "объект"?
Или просто данные, а объектом можно сделать некую другую сущность "менеджер заказов", который умеет управлять их состоянием?
Т.е. почему бы не построить модель происходящего, приближенного к реальной?

Вот "заказ" — это ж мёртвая бумага, носитель.
"Менеджер" — живой человек, он берёт заказ и что-то с ним делает.
"Склад" представлен работниками склада, которые совершают движения ТМЦ согласно "накладных".

Опять же "накладная — это просто инфа на неживом носителе.
Запись в реестре ТМЦ (регистры) — это тоже неодушевлённые сущности, просто инфа на мёртвом носителе.
Но "кладовщик" внесёт туда поправки — скорректирует регистры по изменившимся в кол-ве ТМЦ.
И т.д.

Здравствуйте, Terix, Вы писали:

T>У тебя был аргумент — почему не добавить к объекту методы, которые реализуют логику, которая ему принадлежит. Мой — сущности, которые ты вытаскиваешь из БД объектами не являются, поэтому твой аргумент тут не применим.

А сущность "заказ" — это тоже "объект"?
Или просто данные, а объектом можно сделать некую другую сущность "менеджер заказов", который умеет управлять их состоянием?
Т.е. почему бы не построить модель происходящего, приближенную к реальной?

Вот "заказ" — это ж мёртвая бумага, носитель.
"Менеджер" — живой человек, он берёт заказ и что-то с ним делает.
"Склад" представлен работниками склада, которые совершают движения ТМЦ согласно "накладных".

Опять же "накладная — это просто инфа на неживом носителе.
Запись в реестре ТМЦ (регистры) — это тоже неодушевлённые сущности, просто инфа на мёртвом носителе.
Но "кладовщик" внесёт туда поправки — скорректирует регистры по изменившимся в кол-ве ТМЦ.
И т.д.