工作流UI集成 - WF是一种好方法吗？

与this question有些相似，除了我们还没有确定我们将使用WF。工作流UI集成 - WF是一种好方法吗？

我正在设计一个系统，需要一系列关于“工作对象”的决定和活动，所以我自然开始考虑工作流程，特别是WF。我想知道是，如果WF是像下面（简单化了这个问题）的情况下的情况下很好地解决（请原谅坏的ASCII艺术）：

   __________________ 
      | Gather some info | 
      | (web page) | 
      |__________________| 
         | 
         | 
        /\ 
        / \ 
       / \ 
       /  \ 
       /cond \ 
       \ 1 /
        \  /
        \ /
        \ /
        \/
         | 
         | 
     ______________|_______________ 
     |        | 
     |        | 
     |      ______|______ 
______|________    /do some /
| Get more info |   /process /
| (web page) |   /____________/ 
|_______________| 
     | 
     | 
    /\ 
    / \ 
    / \ 
    /cond. \ 
    \ 2 /
    \ /
     \ /
     \/
     | 
     | 
     |__________________ 
     |     | 
     |     | 
    _____|_____  _____|_____ 
/ some / /another/
/process/ /process/
/__________/  /__________/

我与挣扎的部分是get more info (web page)一步以及随后会发生什么，这意味着工作流运行时的执行会停止。我知道这是可能的，但我不确定WF是这种类型代码的最佳方法，因为在整个工作流程中许多不同点可能需要用户交互，并且工作流将驱动哪些数据输入屏幕是需要的。我们正在使用一个WinForms/ASP.NET Web窗体包，这是一个本地出现且很难推送部署的UI，因此像SharePoint集成这样的事情是不可能的。我们的后端是DB2，工作流代码（无论是WF还是其他）都需要与之交互。

我想底线是，我们应该考虑使用WF来做这件事吗？或者我们可以更好地为自己编码？ WF能否轻松整合数据输入屏幕来捕获可在工作流程中进一步使用的信息？

来源

2010-03-30 AJ.

使用WF的长时间运行的工作流程功能，我相信它会起作用。您的工作流可以随时保存到数据库中。如果要填写几个条件表单，请将其定义作为工作流程中的步骤（有多种方法可以解决此问题）。这样，工作流程不仅可以驱动流程，还可以驱动数据请求。

当工作流程持续存在时，用户可以通过该工作流程继续工作来“唤醒”工作流程。应用程序（ASP.NET，Winforms等）可以查询工作流以找出抽象的“表单”。

来源

2010-03-30 16:58:55

工作流UI集成 - WF是一种好方法吗？

回答

相关问题