Привет, народ!
Есть потребность включить в программу-двухзвенку (клиент — C#, сервер — MS SQL), имеющую перспективу стать техзвенкой, обработку объектов в стиле workflow.
Действия над объектами выполняются по выбору пунктов меню пользователем (т.е. пункт меню — это действие рабочего потока). StateMachine в этом плане подходит идеально.
Предусматривается разграничение прав доступа к действиям и состояниям. Раздача прав будет производиться в рантайме, т.к. заранее группы пользователей не известны.
Сам конечный автомат тоже должен правиться в рантайме (можно добавлять/удалять состояния, действия, изменять топологию графа переходов).
Соответственно "зашивать" права доступа и струтуру автомата в код нельзя. Очевидно, придется хранить назначение прав в таблицах СУБД.
GUI клиента должен конфигурироваться в зависимости от доступности действий (грубо говоря, если у пользователя нет права на выполнение действия X, то пункт меню, связанный с этим действием должен быть либо задизаблен, либо невидим).

Собственно вопрос: имеет ли смыл при перечисленных выше требованиях смотреть в сторону WWF или лучше реализовать самому?

Здравствуйте, Аноним, Вы писали:

А>Собственно вопрос: имеет ли смыл при перечисленных выше требованиях смотреть в сторону WWF или лучше реализовать самому?

Взять что-нибудь более легковесное, например stateless

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

L>Взять что-нибудь более легковесное, например stateless
Спасибо, но, насколько я понял там состояния и действия указываются в качестве параметров дженерика?
Причем в примере предлагаются перечисления (enums), что предполагает жестко заданный автомат... Мне это не подходит...
Или я что-то упускаю?

Здравствуйте, Аноним, Вы писали:

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

L>>Взять что-нибудь более легковесное, например stateless
А>Спасибо, но, насколько я понял там состояния и действия указываются в качестве параметров дженерика?
А>Причем в примере предлагаются перечисления (enums), что предполагает жестко заданный автомат... Мне это не подходит...
А>Или я что-то упускаю?
Я кажется понял: кроме enum'а можно использовать string (т.е. строковое наименование состояния и метода) или class.
Я прав?

Здравствуйте, Аноним, Вы писали:

А>>Причем в примере предлагаются перечисления (enums), что предполагает жестко заданный автомат... Мне это не подходит...
А>>Или я что-то упускаю?
А>Я кажется понял: кроме enum'а можно использовать string (т.е. строковое наименование состояния и метода) или class.

Вроде можно было.

А>Я прав?

Здравствуйте, Lloyd, Вы писали:
L>Вроде можно было.

С этим понятно. Теперь возникает вопрос о хранении данных для конечного автомата в базе данных. Особенно с учетом возможности отката выполненных действий. Я предполагаю, что в интерфейсе на каждое действие будет своя кнопка (ну или там пункт меню, не важно), а для отмены выполненных действий будет одна кнопка.
Так вот, для обеспечения возможности отмены последнего действия над объектом нужно хранить своего рода "журнал выполненных действий". Этот самый журнал логично представить в виде отдельной таблицы. Один из столбцов этой таблицы-журнала будет содержать ID-шник объекта, над которым проводилось действие. И значение этого столбца ограничено внешним ключом.

И тут всплывает вопрос: объектов, работа с которыми идет по принципу workflow, много. Это и объекты справочника (организации и физ.лица из справочника контрагентов, мат.ценности из справочника мат.ценностей, документы всякие). Объекты эти хранятся каждый в своей таблице базы данных. И получается, что внешний ключ по-человечески использовать нельзя... Надо либо какую-то общую таблицу для всех объектов, поддерживающих workflow, делать, а ее уже "расширять" таблицами под конкретный вид объекта; либо на каждую таблицу с объектами заводить свою таблицу-журнал.
Первый вариант плох тем, что общая таблица становится "узким местом", т.к. содержит количество строк равное общему количеству ВСЕХ объектов, поддерживающих workflow.
Второй вариант плох тем, что надо писать много повторяющегося единообразного кода для работы с таблицей-журналом каждого объекта.

Может у меня вообще взгляд на workflow неправильный? Направьте на пусть истинный пожалуйста!

Здравствуйте, Аноним, Вы писали:

А>И тут всплывает вопрос: объектов, работа с которыми идет по принципу workflow, много. Это и объекты справочника (организации и физ.лица из справочника контрагентов, мат.ценности из справочника мат.ценностей, документы всякие). Объекты эти хранятся каждый в своей таблице базы данных. И получается, что внешний ключ по-человечески использовать нельзя... Надо либо какую-то общую таблицу для всех объектов, поддерживающих workflow, делать, а ее уже "расширять" таблицами под конкретный вид объекта; либо на каждую таблицу с объектами заводить свою таблицу-журнал.
А>Первый вариант плох тем, что общая таблица становится "узким местом", т.к. содержит количество строк равное общему количеству ВСЕХ объектов, поддерживающих workflow.
А>Второй вариант плох тем, что надо писать много повторяющегося единообразного кода для работы с таблицей-журналом каждого объекта.

У меня на работе в подобной ситуации журнал не хранится, а прописываются права на обратное движение по схеме workflow. В принципе не сталкивались пока с каким то неудобством. К тому же не все переходы между состояниями можно просто откатить, приходится делать специальные схемы для отмены.

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

_>У меня на работе в подобной ситуации журнал не хранится, а прописываются права на обратное движение по схеме workflow.
Что значит "прописываются права"? Так или иначе это по-любому значит, что в каком-то хранилище (таблице наверное) для каждой сущности прописывается список допустимых действий отката и состояний, в которые переходит сущность посла выполнения соотвествующего действия отката. А разве это не журнал?
Или у Вас по-другому реализовано?
Может быть у Вас считается, что в некоторое состояние X сущность может перейти только из одного состояния?

_> К тому же не все переходы между состояниями можно просто откатить, приходится делать специальные схемы для отмены.
Здесь согласен, но это уже я планирую оставить на совести разработчика, который конкретный workflow для конкретного типа сущностей будет программировать.

Здравствуйте, Аноним, Вы писали:

А>Что значит "прописываются права"? Так или иначе это по-любому значит, что в каком-то хранилище (таблице наверное) для каждой сущности прописывается список допустимых действий отката и состояний, в которые переходит сущность посла выполнения соотвествующего действия отката. А разве это не журнал?

Если брать за определение журнала ваш предыдущий пост, то это не журнал.

А>Или у Вас по-другому реализовано?
А>Может быть у Вас считается, что в некоторое состояние X сущность может перейти только из одного состояния?

У нас не хранится история переходов между состояниями(журнал). Только текущее состояние и описание куда и при каких условиях можно из него перейти(workflow).

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

_>Только текущее состояние и описание куда и при каких условиях можно из него перейти(workflow).

А как в этом случае определить, куда возвращаться при откате?