ASP.NET и Windows Workflow (WF). Нужно ли вставлять его в состояние «Приложение»? - PullRequest
1 голос
/ 19 ноября 2008

Я пытался использовать WF в своем приложении ASP.NET (на самом деле это ASP.NET MVC ... но тот факт, что это MVC вместо WebForms не должен иметь никакого значения).

Теперь я могу запустить WF, и он работает нормально и т. Д., Но он запускается АСИНХРОННО, поэтому любые результаты из WF (хорошо или плохо) теряются на жизненном цикле страницы.

Я нашел статью MSDN , в которой говорится, что в приложениях ASP.NET нам нужно

  • Переведите WorkflowRuntime в состояние приложения
  • К экземпляру WorkflowRuntime добавлен ManualWorkflowSchedulerService (что бы это ни было).
  • При необходимости используйте этот экземпляр рабочего процесса состояния приложения.

Это отличается от того, как я научился это делать:

  • Сделать WorkflowRuntime статическим объектом, который сначала создается при необходимости.
  • Используйте этот статический экземпляр WorkflowRuntime в новом рабочем процессе, который вы собираетесь запустить.

Так ... какой путь лучше? Нужно ли вставлять его в приложение? Каковы различия между ними?

Я понимаю, что на самом деле здесь два вопроса ...

  • Состояние приложения и статический объект (с использованием блокировки / нуля или двойная проверка нуля )
  • DefaultWorkFlowSchedulerService против ManualWorkFlowSchedulerService

ура!

EDIT:

  • Ответ на первый вопрос здесь .
  • На второй вопрос дан ответ ниже.

1 Ответ

4 голосов
/ 20 ноября 2008

Я не уверен насчет вашего первого вопроса (хотя я подозреваю , что они эквивалентны). Тем не менее, я уверен в втором вопросе: вы обязательно должны пойти с ManualWorkflowSchedulerService. Основными причинами являются следующие:

  • Это единственный способ заблокировать выполнение хост-приложения, пока экземпляр рабочего процесса не станет свободным. Обратите внимание, что вы должны явно использовать метод RunWorkflow.
  • ManualWorkflowSchedulerService повторно использовать поток, который сделал веб-запрос ASP.NET для запуска экземпляра рабочего процесса. Это гарантирует, что в любое время число активных потоков в среде выполнения рабочего процесса будет равно числу активных веб-запросов в процессе ASP.NET.

Проверьте этот образец для более.

...