拥有一个大的工作流程还是几个较小的特定工作流程更好？
我需要构建一个从服务器获取文件并移动到另一台服务器的应用程序。 有人建议我考虑使用 Windows Workflow Foundation (WF)。
我开始构建工作流程，但它变得越来越混乱，我不确定我是否以最好的方式做到了这一点。
以下是基本工作流程活动：
获取来源列表 确定源是 ftp 还是磁盘驱动器 从服务器获取文件列表 如果源是 ftp，则使用 ftp get 获取文件，否则如果源是驱动器，则从驱动器读取文件 如果目标是 ftp，则将 ftp 文件发送到服务器，否则如果目标是驱动器，则写入驱动器，否则如果目标是 Web 服务，则发布到 Web 服务 如果源是 ftp，则使用 ftp 命令删除文件，否则如果源是驱动器，则删除文件
通过一个工作流程，它会变得有点忙。 我需要 2 个 while 循环，一个围绕集成，一个在获得文件列表之后。
我想到的另一件事是构建多个工作流程。 一种用于 FTPtoFTP、FTPtoDrive、FTPtoWebServie、DriveToFTP、DrivetoDrive、DriveToWebService。
有什么建议么？
I need to build an app that gets files from a server and moves to another server. It was suggested that I look into using Windows Workflow Foundation (WF).
I started to build the workflow but it is getting messy and I'm not sure I'm doing it the best way possible.
Here is the basic worklow activities:
Get a list of sources
Determine if source is ftp or disk drive
Get a list of files from the server
If source is ftp then get the file with ftp get else if source is drive then read file from drive
If target is ftp then ftp file to server else if target is drive then write to a drive else if target is web service then post to web service
If source is ftp then delete file with ftp commands else if source is drive then delete file
With one workflow it gets a little busy. I need 2 while loops, one around the integrations and one after I get a file list.
The other thing I thought of was to build multiple workflows. One for FTPtoFTP, FTPtoDrive, FTPtoWebServie, DriveToFTP, DrivetoDrive, DriveToWebService.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，您应该考虑为每个主要部分创建自定义活动。 自定义活动将是可由许多步骤组成的复合活动。 这将有助于整理一些事情，并允许您继续在相对较高的级别上使用工作流程。
工作流程设计器虽然方便，但并不是真正设计用于大规模扩展。 从 VS 2008 开始，使用基于 XAML 的技术的最佳方法是使用文本编辑器并直接读取/写入 XML。
将其分解为多个工作流可能不是最好的方法，除非您可以将其分解为几个高级活动并在 XAML 级别工作。 请记住，如果所有这些的逻辑和流程几乎相同，那么您现在必须维护 6 个不同的工作流程。 如果您的工作流程很复杂并且您需要修复所有工作流程中的常见逻辑错误，那么这将是一场更大的噩梦。
您还应该考虑服务的使用。 这可能允许您拥有一个工作流程和一组活动，但每个步骤的实现都可以隔离到一个服务中。 在这种情况下，您需要为每个组合实例化一个工作流，将相同的工作流加载到每个组合中，并注入不同的活动。 不一定是最好的方法，但需要考虑。
First, you should consider creating custom Activities for each of the major sections. The custom activities will be Composite Activities that can be composed of many steps. This will help de-clutter things a bit and allow you to continue working with the workflows at a relatively high-level.
The Workflow Designer, while handy, is not really designed to scale very large. As of VS 2008, the best way to work with XAML-based technologies is to use the text editor and read/write the XML directly.
Breaking it down into several workflows might not be the best approach unless you can break it down into a few high-level activities and are working at the XAML level. Keep in mind that if the logic and flow is nearly identical for all of these, you will now have to maintain 6 different workflows. This is a bigger nightmare if your workflows are complex and you need to fix a common logic error across all of them.
You should also consider the use of the Services. This may allow you to have ONE workflow and ONE set of activities, but the implementation of each step can be isolated into a service. In this case, you would need to instantiate one workflow per combination, load the same workflow into each, and inject different activities. Not necessarily the best approach, but something to consider.
首先，在我看来，使用 WF 给本应相当简单的过程增加了额外的复杂性。 尽管 WF 可用于对执行流进行建模，但其目的是对业务流进行建模，并包含业务规则和逻辑，而不将它们放入您的实现中。
在您的示例中，业务规则看起来很大程度上像是应该由 app.config 文件处理的事情。
然而，关于使用一个或多个工作流程的更广泛的问题。 您希望每个工作流程任务都具有大致相同的“广泛范围”
例如
建造桌子的WF
中间的台阶比周围的台阶要详细得多。
因此，您可以考虑将其分成两个单独的工作流程：包含广泛步骤的高级工作流程和包含细节的较低级别工作流程。
因此，“GetDatasource”工作流步骤不会关心（外部）它从什么类型的数据源收集，它只是将一组数据返回到工作流中的下一步。
目标也是如此，它不关心它有什么类型的数据源，它只关心它与数据有什么关系。 所以这也应该被封装。
因此，您的工作流程可以是三个工作流程
最高 WF
然后您的 DoThingsWithDataWF 和 GetDataSourceWF 工作流程可以各自只关注它们需要的执行上下文。
编辑
正如评论者 James Schek 所指出的。
您可以使用较高级别的工作流程来实际启动较低级别的工作流程并相互管理它们的执行。
First of all, this sounds to me like using WF is adding extra complications to what should be a fairly straightforward process. Although WF can be used to model execution flow, its purpose is to model business flow, and include business rules and logic without putting those into your implementations.
In your example, the business rules seem largely like things which should be dealt with by an app.config file.
However, on the broader question of using one workflow or many. You want each of your workflow tasks to be approximately the same 'broad scope'
For instance
WF for building a table
The steps in the middle are all much more detailed than the steps around them.
So you would consider splitting it up into two separate workflows: a high level workflow that contains the broads steps, and lower level workflows that contain the particulars.
So the 'GetDatasource' workflow step would not care (externally) what type of datasource it is gathering from, it just returns to the next step in the workflow a set of data.
Same goes for target, it doesn't care what type of datasource it had, it only cares what it has to do with the data. So that should be encapsulated as well.
So your Workflow could be three workflows
Highest WF
Then your DoThingsWithDataWF and GetDataSourceWF Workflows can each be concerned with only the execution context that they need.
EDIT
As pointed out by the commenter James Schek.
You can use the higher level workflow to actually kick off your lower level workflows and manage their execution into each other.
就我个人而言，我还没有使用过 WWF。 不过，我之前已经完成了相当多的工作流程。 对我来说，将它们分解成更小的工作流程似乎是最好的方法。 当您使用工作流时，您应该尝试将每个工作流限制为特定任务，以便您有明确的开始操作以及至少一条成功路线和至少一条失败路线。 一般来说，工作流程可能非常棘手，最好让每个流程尽可能简单。
Well personally I have not used WWF yet. I have done quite a bit of workflows before though. To me breaking them up into smaller workflows would seem to be the best way. When you're working with workflows you should try to limit each workflow to a specific task so that you have a definitive start action and at least one successful route and at least one failure route. Workflows in general can be very tricky things and it's best to keep each as simple as possible.
一般来说，只要事情变得“混乱”，你就应该将它们分解成更小的部分。 我绝对建议将其分解为几个工作流程。
As a general rule, anytime things get "messy", you should break them down into smaller parts. I'd definitely recommend breaking it down into several workflows.