Проблемы проектирования рабочего процесса Foundation / Соображения? - PullRequest
3 голосов
/ 21 августа 2011

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

1) Внутри рабочего процесса все переменные являются либо глобальными, либо областью действия. Если вы хотите связать их с входным / выходным аргументом действия, тогда они должны быть глобально ограничены. И все мы имели дело с управлением долговременными переменными в глобальном масштабе.

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

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

2) Модульное тестирование, я вижу, как можно проверить каждое действие, но я пока не вижу, как можно протестировать рабочий процесс в целом. Например. Как я должен имитировать рабочий процесс, отправляющий электронное письмо, когда он не получает ввод от пользователя через 30 дней? Тем не менее, мне неудобно полностью исключать модульный тест, поскольку рабочий процесс, в конце концов, является логикой ветвления, а значит, и сложной, поэтому вероятность ошибки слишком велика, чтобы ее игнорировать.

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

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

Я просто слишком обороняюсь? Что вы берете? Как я могу избежать ловушек?

Заранее спасибо!

1 Ответ

2 голосов
/ 21 августа 2011

Похоже, что вы смотрите на WF 3.5, а не на WF 4.

1) Внутри рабочего процесса все переменные являются либо глобальными, либо областью действия.

В WF 4 представлены контейнерные действия, которые создают области.

2) Юнит-тестирование.

См. Windows Workflow Foundation на CodePlex , особенно Microsoft.Activities.модульное тестирование.Книга Pro WF: рабочий процесс Windows в .NET 4.0 содержит примеры операций модульного тестирования.Помните, что рабочие процессы и действия взаимозаменяемы.См. WorkflowInvoker.Invoke для одного способа синхронного выполнения рабочего процесса (или действия) в модульном тесте.

3) Весь фундамент рабочего процесса выглядит так сильно связанным

WF 4 не связывает постоянство, для одного.

И да, рабочие процессы могут быть нарушены;см. Опасность централизованных рабочих процессов .Я полагаю, что у них есть место для длительных процессов, в которых участвуют люди.

...