Как сохранить объекты, когда для фактического внесения изменений необходимо одобрение?

Question

Итак, у меня есть граф объектов, скажем так, это порядок. У вас есть класс заказа, класс позиции, класс номера отслеживания, класс оплаты. Вы поняли идею.

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

Каковы лучшие практики для решения подобных ситуаций? Сохранение множества (возможных) различных состояний объекта заказа и в конечном итоге утверждение или отклонение изменений.

Я использую C # и Nhibernate.

Спасибо, Кайл.

Answer 1

Аналогично представлению Сэма Уильямсона о таблице транзакций, я бы использовал временную таблицу.

Изменения, сделанные кем-то, кто не является менеджером, перейдите к новым объектам Order в таблице temp. Менеджер будет иметь интерфейс для просмотра этих заказов в ожидании одобрения, и в системе все изменения будут сохранены, но за пределами стандартной позиции.

Это может быть проблемой и для пользовательского интерфейса, они должны будут видеть как официальную версию заказа, так и версию, ожидающую рассмотрения, чтобы понять состояние объекта.

В любом случае, я думаю, что вам лучше всего хранить объекты в обычном режиме, но в отдельной таблице от официальных записей, в ожидании рассмотрения менеджером. Эта временная таблица никогда не должна становиться очень большой, поскольку она представляет собой отставание утверждений, к которому должен обратиться менеджер.

Answer 2

Я бы создал таблицу транзакций. Он будет иметь запись для каждого ожидающего изменения. Это будет ссылаться на таблицу заказов.

Таким образом, заказ будет создан, но с ожидающим изменением; запись будет вставлена ​​в таблицу заказов с указанием ожидающего столбца состояния, а запись будет добавлена ​​в таблицу OrderTransaction.

Для каждого изменения в таблицу OrderTransaction вставляется другая запись.

Я бы также настроил таблицу RequestedChanges со всеми возможными запрошенными изменениями.

Answer 3

Если заказы не завершены до их утверждения, вы можете захотеть иметь отложенные заказы и структуру таблицы завершенных заказов. Отложенные ордера могут быть просто сериализованными объектами и записывать их в заказ, строки заказа и т. Д. Только после утверждения.

Если вы разрешаете изменять заказы после того, как утверждение станет более сложным, вам также может потребоваться принять во внимание этапы после утверждения, полученную оплату, комплектацию, упаковку, доставку и т. Д.

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

Answer 4

простое решение состоит в том, чтобы просто сделать другой заказ, который является копией оригинала с примененными изменениями, состоянием, установленным в PendingApproval, и автоматически увеличивающим VersionNumber. измените первичный ключ таблицы, чтобы включить ApprovalDate. Тогда текущим утвержденным заказом всегда является тот, с самой последней датой утверждения.

Answer 5

У меня нет опыта работы с nHibernate.

Для такого сценария лучше оставить базу данных для хранения Order (state = ForManagerToApproveOrReject), а затем его можно запросить, чтобы увидеть, какие Заказы ожидают утверждения / отклонения (с точки зрения менеджера)

Менеджер может либо одобрить, либо отклонить его. Режим наследования сохранения Order (ApprovedOrder, RejectedOrder) кажется немного странным.

Answer 6

спасибо за все ответы. Фактический бизнес-пример не создает заказы, но если бы я попытался объяснить реальный бизнес, мне пришлось бы написать пару параграфов. Суть в том, что менеджерам нужно модерировать изменения в глубоко вложенном объектном графе, прежде чем они начнут работать.

Мне нравится идея таблицы транзакций.

Мне также нравится сохранять две версии "заказа", одну с изменениями, одну без.

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

Answer 7

То, что вы описываете, является рабочим процессом, на самом деле мне кажется хорошим кандидатом на Windows Workflow Foundation . Если ваш рабочий процесс критичен для бизнеса, я бы хотел отделить его от логики вашей базы данных, WWF позволит вам сделать это.

Answer 8

Я понимаю эту часть, проблема в том, что я выясняю, как / где сохранить все изменения, пока заказ не утвержден. Например, пользователь A добавляет платеж, пользователь B меняет адрес, а пользователь C добавляет новую позицию.

до тех пор, пока менеджер не подтвердит, что заказ остается таким же, каким он был изначально создан (или получен из БД). Когда менеджер находится на экране подтверждения, он / она может одобрить / отклонить каждое изменение. Изменения записываются в исходный порядок и аудит сохраняется. Пользователь A изменил xxx на yyy, утвержденный zzz на aaa.