ASP.NET 和 Windows 工作流 (WF) - 我们需要将其保持在应用程序状态吗？
我一直在尝试在我的 ASP.NET 应用程序中使用 WF（实际上，它是 ASP.NET MVC ...但事实上它是 MVC 而不是 WebForms 根本不重要）。
现在，我可以运行 WF 并且它工作正常，等等，但它是异步启动的，因此 WF 的任何结果（好或坏）都会丢失页面生命周期。
我发现了一篇 MSDN 文章说在 ASP.NET 应用程序中，我们需要
- 将
WorkflowRuntime放入应用程序状态 WorkflowRuntime实例添加了一个ManualWorkflowSchedulerService（无论什么）那是）。- 需要时使用此应用程序状态工作流实例。
这与我学习的方式不同：
- 将 WorkflowRuntime 设为静态对象，在需要时首先创建。
- 在您要运行的新工作流上使用此静态 WorkflowRuntime 实例。
那么...哪种方式更好？ 我们需要将其粘贴到应用程序中吗？ 两者有何区别？
我知道这里实际上有两个问题...
- 应用程序状态与静态对象（使用 lock/null 或 双空检查）
- DefaultWorkFlowSchedulerService vs ManualWorkFlowSchedulerService
欢呼！
编辑：
- 第一个问题的答案此处。
- 下面回答第二个问题。
I've been trying to use WF in my ASP.NET application (actually, it's ASP.NET MVC ... but the fact that it's MVC instead of WebForms should not matter at all).
Now, I can run the WF and it works fine, etc, but it kicks off ASYNCHRONOUSLY, so any results from the WF (good or bad) get lost page life cycle.
I found an MSDN article that says that in ASP.NET applications, we need to
- Put the
WorkflowRuntimeinto the Application state - The
WorkflowRuntimeinstance has aManualWorkflowSchedulerServiceadded to it (whatever that is). - Use this application state workflow instance when required.
This is different than how I learned to do it:
- Make the WorkflowRuntime a static object, that is first created when required.
- Use this static WorkflowRuntime instance on the new workflow you're going to run.
So ... which way is better? Do we need to stick it into the application? What are the differences between the two?
I understand there's actually TWO questions here...
- Application state vs static object (using lock/null or double null checking)
- DefaultWorkFlowSchedulerService vs ManualWorkFlowSchedulerService
cheers!
EDIT:
- First question is answered here.
- Second question is answered below.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定你的第一个问题（尽管我怀疑它们是等价的）。 但是，我确信第二个问题：您一定要使用
ManualWorkflowSchedulerService。 主要原因如下：RunWorkflow方法。ManualWorkflowSchedulerService重用发出 ASP.NET Web 请求的线程来运行工作流实例。 这可确保在任何时候，工作流运行时中的活动线程数等于 ASP.NET 进程中的活动 Web 请求数。查看此示例了解更多信息。
I am not sure about your first question (although I suspect that they are equivalent). However, I am sure for the second question: You must definitely go with the
ManualWorkflowSchedulerService. The main reasons are the following:RunWorkflowmethod.ManualWorkflowSchedulerServicereuse the thread that made the ASP.NET Web request to run the workflow instance. This ensures that at any time, the number of active threads in the workflow runtime equals the number of active Web requests in the ASP.NET process.Check this sample for more.