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