拥有一个大工作流程或几个较小的特定工作流程会更好吗？
我需要构建一个从服务器获取文件并移动到另一台服务器的应用程序。 有人建议我考虑使用Windows Workflow Foundation（WF）。
我开始构建工作流程，但它变得混乱，我不确定我是以最好的方式做到这一点。
这是基本的worklow活动：
获取源列表确定源是ftp还是磁盘驱动器从服务器获取文件列表如果source是ftp然后使用ftp获取文件如果source是drive则获取else然后从驱动器读取文件如果target是ftp则ftp文件到服务器如果目标是驱动器然后写入驱动器，如果目标是Web服务然后发布到Web服务如果源是ftp然后删除文件与ftp命令否则如果源是驱动器然后删除文件
通过一个工作流程，它会变得有点繁忙。 我需要2个while循环，一个在集成周围，一个在我得到文件列表之后。
我想到的另一件事是构建多个工作流程。 一个用于FTPtoFTP，FTPtoDrive，FTPtoWebServie，DriveToFTP，DrivetoDrive，DriveToWebService。
有什么建议？
首先，您应该考虑为每个主要部分创建自定义活动。 自定义活动将是复合活动，可以由许多步骤组成。 这将有助于解决一些问题，并允许您继续使用相对较高级别的工作流程。
工作流设计器虽然方便，但实际上并不是为了扩展而设计的。 从VS 2008开始，使用基于XAML的技术的最佳方法是使用文本编辑器并直接读/写XML。
将其分解为多个工作流可能不是最佳方法，除非您可以将其分解为几个高级活动并且正在XAML级别工作。 请记住，如果所有这些逻辑和流程几乎相同，那么您现在必须维护6个不同的工作流程。 如果您的工作流程很复杂并且您需要修复所有这些工作流程中的常见逻辑错误，那么这是一个更大的噩梦。
您还应该考虑使用服务。 这可能允许您拥有一个工作流程和一组活动，但每个步骤的实施可以分离到一个服务中。 在这种情况下，您需要为每个组合实例化一个工作流，将相同的工作流加载到每个工作流中，并注入不同的活动。 不一定是最好的方法，但需要考虑的事情。
首先，这对我来说听起来像使用WF会给应该是一个相当简单的过程增加额外的复杂性。 尽管WF可用于建模执行流程，但其目的是对业务流程进行建模，并包含业务规则和逻辑，而无需将其纳入您的实现。
在您的示例中，业务规则看起来很像应该由app.config文件处理的事情。
但是，关于使用一个或多个工作流程的更广泛问题。 您希望每个工作流任务与“广泛范围”大致相同
例如用于构建表的WF
- 购买木材
- 切木头
- 为木腿切割
- 斜边
- 圆形飞檐
- 沙子两次，粗糙度不同
- 组装表
中间的步骤比周围的步骤更详细。 因此，您可以考虑将其拆分为两个单独的工作流程：包含广泛步骤的高级工作流程，以及包含详细信息的较低级别工作流程。
因此，’GetDatasource’工作流程步骤不关心（外部）它从哪个类型的数据源收集，它只是返回工作流程中的下一步一组数据。
同样适用于目标，它不关心它具有什么类型的数据源，它只关心它与数据有什么关系。 所以这也应该被封装。
因此，您的工作流程可能是三个工作流程
最高的WF
- GetDataSourceWF
- DoThingsWithDataWF
然后，您的DoThingsWithDataWF和GetDataSourceWF工作流都可以只关注它们所需的执行上下文。
编辑
正如评论者James Schek所指出的那样。 您可以使用更高级别的工作流程来实际启动较低级别的工作流程并相互管理它们的执行。
我个人还没有使用WWF。 我之前做过很多工作流程。 对我来说，将它们分解为更小的工作流程似乎是最好的方法。 当您使用工作流时，您应该尝试将每个工作流限制为特定任务，以便您具有明确的启动操作以及至少一个成功路由和至少一个故障路由。 一般来说，工作流程可能是非常棘手的事情，最好保持每个工作流程尽可能简单。
作为一般规则，任何时候事情变得“混乱”，你应该把它们分解成更小的部分。 我绝对建议将其分解为几个工作流程。