拥有一个大工作流程或几个较小的特定工作流程会更好吗？

Question

我需要构建一个从服务器获取文件并移动到另一台服务器的应用程序。有人建议我考虑使用Windows Workflow Foundation（WF）。

我开始构建工作流程，但它变得混乱，我不确定我是以最好的方式做到这一点。

以下是基本的worklow活动：

获取来源列表 确定源是ftp还是磁盘驱动器 从服务器获取文件列表 如果source是ftp，那么如果source是drive则从ftp获取文件，然后从驱动器读取文件 如果target是ftp，那么ftp文件到服务器else如果target是drive然后写入驱动器，如果target是web服务然后发布到web服务 如果source是ftp，则使用ftp命令删除文件，否则如果source是drive则删除文件

有一个工作流程就会有点繁忙。我需要2个while循环，一个在集成周围，一个在我得到文件列表之后。

我想到的另一件事是构建多个工作流程。一个用于FTPtoFTP，FTPtoDrive，FTPtoWebServie，DriveToFTP，DrivetoDrive，DriveToWebService。

有什么建议吗？

Answer 1

首先，您应该考虑为每个主要部分创建自定义活动。自定义活动将是复合活动，可以由许多步骤组成。这将有助于解决一些问题，并允许您继续使用相对较高级别的工作流程。

工作流设计器虽然很方便，但实际上并不是为了扩展而设计的。从VS 2008开始，使用基于XAML的技术的最佳方法是使用文本编辑器并直接读/写XML。

将其分解为多个工作流可能不是最佳方法，除非您可以将其分解为几个高级活动并且正在XAML级别工作。请记住，如果所有这些逻辑和流程几乎相同，那么您现在必须维护6个不同的工作流程。如果您的工作流程很复杂并且您需要修复所有这些工作流程中的常见逻辑错误，那么这就是更大的噩梦。

您还应该考虑使用服务。这可能允许您拥有一个工作流程和一组活动，但每个步骤的实现可以分离为一个服务。在这种情况下，您需要为每个组合实例化一个工作流，将相同的工作流加载到每个工作流中，并注入不同的活动。不一定是最好的方法，但需要考虑的事情。

Answer 2

首先，这对我来说听起来像使用WF会给应该是一个相当简单的过程增加额外的复杂性。尽管WF可用于建模执行流程，但其目的是为业务流建模，并包含业务规则和逻辑，而无需将其放入您的实现中。

在您的示例中，业务规则看起来很像应该由app.config文件处理的事情。

然而，关于使用一个或多个工作流程的更广泛问题。您希望每个工作流任务与“广泛范围”大致相同

例如 用于建造桌子的WF

• 购买木材
• 切木
• 为腿剪木头
• 斜边
• 圆形檐口
• 两次不同粗糙的沙子
• 汇编表

中间的步骤比周围的步骤更详细。 因此，您可以考虑将其拆分为两个单独的工作流程：包含广泛步骤的高级工作流程，以及包含详细信息的较低级别工作流程。

因此，'GetDatasource'工作流程步骤不关心（外部）它从中收集哪种类型的数据源，它只是返回工作流程中的下一步数据集。

同样适用于目标，它不关心它具有什么类型的数据源，它只关心它与数据有什么关系。所以这也应该被封装。

因此，您的工作流程可以是三个工作流程

最高WF

1. GetDataSourceWF
2. DoThingsWithDataWF

然后你的DoThingsWithDataWF和GetDataSourceWF工作流都可以只关注他们需要的执行上下文。

修改

评论者James Schek指出。 您可以使用更高级别的工作流程来实际启动较低级别的工作流程并相互管理它们的执行。

Answer 3

我个人还没有使用WWF。我之前做过很多工作流程。对我来说，将它们分解成更小的工作流程似乎是最好的方法。当您使用工作流时，您应该尝试将每个工作流限制为特定任务，以便您具有明确的启动操作以及至少一个成功路由和至少一个故障路由。一般来说，工作流程可能是非常棘手的事情，最好尽量保持每个工作流程。

Answer 4

作为一般规则，任何时候事情变得“混乱”，你应该将它们分解成更小的部分。我绝对建议将其分解为几个工作流程。