Windows 生产代码中的工作流

嗨，我想知道你们中有多少人在生产环境中使用过工作流，这是个好主意吗？我的意思是，我们可以使用DB和scheduler service创建相同的东西。我们使用Sharepoint，它的工作流使用WF。它工作得很好，而且很容易定制。如果你需要一个高级的工作流程，WF可以支持它，但是需要一些培训来了解细节

---

你可以使用自己的工作流程，但为什么要重新发明轮子呢？WF内置于.NET 3.0+框架中，非常健壮，因此您不妨利用它。

我们在生产环境中使用WF。我们可以运行6种不同的工作流。它们分为3个状态机和3个序列。在某些情况下我会再次使用它，但在其他情况下我不会。我认为工作流中的状态机部分很快就被添加到了末尾，我不确定它在整个设计过程中都是工作流的核心部分

在将它们发送给供应商之前，我会再次将工作流用于短时间运行的流程，如引用或转换内容

对于长时间运行的状态机，我不想再这样做了——主要是因为没有内置的WF升级过程，所以我们最终编写了自己的。还有很多概念需要你去思考（在我们的开发团队中，我们称之为吉普赛诅咒）

我也会有点担心性能：我们的应用服务器目前正在全速运行（好的，我现在正在重新启动8000个工作流）。如果您使用（.NET 3.5）发送和接收活动将其直接集成到WCF中，这尤其是一个问题-您必须设置一些适当的疯狂配置设置，以允许它同时运行多个工作流

无论如何，正如我所说：它很有用，我会再次使用它，但不会用于另一个状态机

---

另请参见

大多数人都说工作流有很多优点，但我发现它们会带来不必要的代码复杂性和维护问题。它们适用于特定类别的问题。除此之外，他们还需要大量的代码管道和维护噩梦

我能问你一些事情吗？你是如何在Sharepoint 2003中编程的？在WF出现之前，我们没有。我们的大部分工作流程都使用Teamcenter Enterprise。我们目前正在研究在Sharepoint 2007中实施更多工作流。