Workflow foundation 4 作为Windows服务托管WF

我正在尝试构造一个简单的windows工作流来监视入站文件的目录，并使用windows WF 4.0进行一些数据库更新。目前，我计划构建一个“WCF工作流服务”，并将其作为一个全天候运行的“Windows服务”托管（每天关闭和启动服务）

在将来，我计划使用ASP.NET/WPF应用程序来创建一个基本的仪表板类型的东西来使用此服务

考虑到对windows服务上承载WF的文件进行目录轮询的想法，这似乎是一个好主意吗？这有什么坏处

---

如果这方面有任何缺点，或者可以通过更好的方法来实现，请给出建议。

我实际上正在这样做，但它比您想象的要复杂一些，如果可能的话，应该避免

您不应该在活动中进行阻止；如果预期它是一个长时间运行的活动，正在等待来自外部的输入（例如，FileSystemWatcher事件），那么工作流应该使自己空闲并等待从外部唤醒

我是如何做到这一点的，我创建了一个承载FileSystemWatcher的工作流扩展。一旦活动准备好监视文件，它就会创建一个书签并将其传递给扩展名

然后分机启动FSW，握住书签

当触发FSW事件时，扩展恢复书签，传入包含事件详细信息的对象。活动执行了事件所需的操作，然后重新安排了自己的时间

通常我不会这样做，但我有一些要求，迫使我使用WF4来实现这个目标。如果我不必使用WF4，我会在服务中启动FSW并使用事件

---

除非您希望在配置中必须非常灵活，详细说明如何处理FSW事件，并希望在部署服务期间经常更改，否则我将跳过WF4。

谢谢。这是否意味着WF的设计不能满足目录/文件监控等需求？在任何使用SOA的行业中，这样的活动不是很常见吗？考虑WF？@ @ SRaLIJ.P：在目录中没有烘焙的活动，这会是一个好主意吗？监控目录是一种老生常谈；现在到底是谁把文件丢到目录里了？哦，等等，我必须这么做。所以你得自己滚。正如我的回答所暗示的那样，你可以通过我描述的“绕圈子”的方式正确地实现它。除非你有很好的理由使用工作流基础4来监视目录，否则我不会推荐它。在您的情况下，最好监视目录，然后生成WF以处理任何创建文件的内容。我想这两个世界都是最好的。这似乎是最好的方式。谢谢你的意见！目录监控似乎很古老，但仍然有许多保险/银行组织以这种方式共享数据文件。我在考虑如何处理FSW，比如将需要处理的文件集移动到另一个目录，以便知道inbound files文件夹中的任何内容都是新的。有什么想法吗？