Проектирование системы для расширяемого рабочего процесса утверждения для различных типов объектов - PullRequest
Новая
       35

Проектирование системы для расширяемого рабочего процесса утверждения для различных типов объектов

0 голосов
/ 17 октября 2018

Я ищу эффективный способ создания черновиков и запуска процесса утверждения для некоторых объектов в моем домене.Пользователи должны легко отслеживать изменения и одобрять или отклонять изменения.Не могли бы вы предложить общую модель / подход / план действий, чтобы легко обеспечить эти функции?

Допустим, у меня есть эта модель: 

public class CourierDistributionArea
{
    public City City { get; set; }
    public Courier Courier { get; set; }
}

public class City
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class Courier
{
    public int Id { get; set; }
    public string Name { get; set; }
}

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

1 Ответ

0 голосов
/ 21 октября 2018

Существует несколько вариантов, и они будут зависеть от вероятных изменений, внесенных вашими пользователями, от того, могут ли несколько пользователей одновременно предоставлять альтернативные черновики, и от того, какое хранилище вы хотите использовать (я не знаю, как некоторые СУБД на основе таблиц, напримерSQL Server).

1.Черновые таблицы

Создайте таблицу CarDraft рядом с таблицей Car.Все столбцы в целевой таблице должны присутствовать в черновой таблице вместе с любыми дополнительными столбцами, которые требуются для метаданных, относящихся к самому черновику.Когда черновик будет утвержден, поместите соответствующие столбцы в целевую таблицу и удалите черновик.

Плюсы

  • Нет необходимости поддерживать несколько версий одного и того жеобъект в той же таблице
  • Черновики никак не влияют на OLTP на целевой таблице

Минусы

  • Дополнительнотаблица для ведения

2.Версионные сущности

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

Плюсы

  • Нет дополнительной таблицы для обслуживания
  • Нет необходимости писать строку дважды (просто удалите старую строку и перевернитеPublished бит нового в одной транзакции)

Минусы

  • Потенциально более сложные ограничения / проверка приложения
  • Дополнительные проверки при присоединении к столбцу Published (легко забыть)

3.Подтверждение преобразования

Опять же, в зависимости от операций, которые пользователи могут выполнять для изменения объектов, вы можете сохранить саму операцию изменения, а не новое состояние как черновик.Это может быть сохранено в таблице CarModifications, например, потенциально как частичный объект JSON, или как число или строки, каждая из которых представляет изменение значения столбца в целевой таблице.Несколько строк могут быть сгруппированы как один OperationId, если необходимо.

Плюсы

  • Нет изменений в целевой таблице
  • Несколько изменений в нескольких таблицахможет быть введен для одного идентификатора операции и применен в транзакции

Минусы

  • Более сложное моделирование
  • Более сложное подтверждение
...