Дилемма Дизайна рабочего процесса - Конечный автомат, да или нет

Государственная машина является очень мощной техникой для реализации, Хотя я бы рекомендовал рассмотреть фреймворк под названием StateLess by Nicholas Blumhardt (создатель Autofaq), так как это удивительно простая реализация государственной машины, которая позволяет избежать ненужной сложности Windows Workflow. Его подход позволяет избежать проблемы длительных рабочих процессов, выполняемых исполняющим движком, так как состояние определяется простой переменной, такой как string или int.

Вот пример машины состояний:

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

phoneCall.Configure(State.Ringing)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.State);

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

var stateMachine = new StateMachine<State, Trigger>(
    () => myState.Value,
    s => myState.Value = s);

Вы можете реализовать это в одной сборке, по сравнению с несколькими проектами, необходимыми для запуска Windows Workflow. Сопровождение крайне низкое, это не "конструктор", который генерирует код для вас и т.д. Опять же, это просто, и в этом кроется прелесть.

Учитывая Ваши дополнения (более 3-х состояний, не все переходы разрешены), я бы сделал следующее:

1. Хранить состояние каждого элемента в самом элементе.
   Этого очень легко добиться: Добавьте член в класс или столбец в таблицу и т.д., как другие уже упоминали в своих сообщениях/комментариях.
2. Используйте одну машину состояний (это может быть что угодно от экземпляра класса до таблицы с правовыми переходами), которая поддерживает вашу бизнес-логику, т.е. допустимые переходы между состояниями и знание о том, какие дополнительные действия нужно выполнить, когда элемент изменяет свое состояние.

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

Хорошо. Посмотрим, смогу ли я вам помочь. Давайте начнем с проектирования:

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

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

И да - вы должны сделать все элементы постоянными в базе данных. Таким образом вы также будете поддерживать очень длительный рабочий процесс - они живут в базе данных до тех пор, пока не будут реактивированы любой активностью. Так делают все системы управления бизнес-процессами (BPMS) с полки. Эти рабочие процессы НЕ хранятся в памяти.

Хранение всего в базе данных облегчит создание отчетов.

Как уже упоминали другие, создайте новый столбец с информацией о состоянии или даже таблицу с мета-данными: состояние, может быть, журнал, когда состояние изменилось, кто изменил состояние, информация о предстоящих событиях (деталь была заказана, но не доставлена - через сколько дней кто-то должен проверить у поставщика, не была ли потеряна поставка?). Это даст вам возможность добавлять мета-данные по мере необходимости, не затрагивая базу данных запчастей.

Надеюсь, это поможет!

Как обсуждалось в комментариях к первоначальному посту, у меня вообще есть некоторые проблемы с использованием ВФ для этой конкретной проблемы.

Стимулом для этого является предложение "Пункты могут проводить месяцы в каждом штате, а их тысячи": Я считаю, что рабочие процессы (смоделированные с помощью WF) должны быть более короткими. Хотя нет никакого жесткого правила о том, как долго может или должен прожить экземпляр WF, несколько месяцев или, может быть, даже лет приводят к "неограниченным" исключениям со мной, особенно когда это было бы очень распространенным состоянием для тысяч элементов :-)

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

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

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

Машины состояний имеют смысл, когда состояния управляют бизнесом, или когда необходимо иметь доверенную единственную часть кода, которая является единственным субъектом, отвечающим за "валидированный переход".

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

Aviad, я согласен с вашим комментарием, что рабочий процесс должен быть между состояниями. Состояния изобретаемых частей звучит как состояние/свойство элемента. Это состояние можно хранить практически любым способом (например, база данных, файл...), т.к. перемещение элемента между состояниями будет жить на уровне бизнес-логики.

Звучит как забавный проект, удачи.