生产代码中的工作流程
您好，我想知道有多少人在生产环境中使用过工作流，这是个好主意吗？ 我的意思是我们可以使用数据库和调度程序服务创建相同的东西
Hi I would like to know how many of you have used Workflow in your production environment and Was it good idea? I mean we can create the same thing using DB and scheduler service
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们使用 Sharepoint，它的工作流程使用 WF。 它工作得很好并且很容易定制。 如果您需要高级工作流程，WF 可以支持，但需要一些培训才能了解细节。
您可以推出自己的工作流程，但为什么要重新发明轮子呢？ WF 内置于 .NET 3.0+ 框架中，并且非常强大，因此您不妨利用它。
We use Sharepoint, which uses WF for its workflows. It works pretty well and is fairly easy to customize. If you need an advanced workflow, WF can support it but it will take some training to learn the ins and outs.
You could roll your own workflow, but why reinvent the wheel? WF is built into the .NET 3.0+ framework and is pretty robust, so you might as well take advantage of it.
我们在生产环境中使用 WF。 我们有 6 个可以运行的不同工作流程。 它们分为 3 个状态机和 3 个序列。 在某些情况下我会再次使用它，但在其他情况下我不会。 我想说工作流程的状态机部分很快就被添加到了最后，我不确定它是整个设计过程中工作流程的核心部分。
我会再次使用工作流程来进行短期运行的流程，例如报价或在将它们发送给供应商之前进行转换之类的事情。
我不想对长时间运行的状态机再次执行此操作 - 主要是因为没有内置的 WF 升级过程，因此我们最终编写了自己的状态机。 还有很多概念需要您理解（在我们的开发团队中被称为吉普赛诅咒）。
我也会稍微担心性能：我们的应用程序服务器当前正在全力运行（好吧，我现在正在重新启动 8000 个工作流程）。 如果您使用 (.NET 3.5) 发送和接收活动将其直接集成到 WCF 中，这尤其是一个问题 - 您必须设置一些相当疯狂的配置设置以允许它同时运行多个工作流。
不管怎样，正如我所说：它很有用，我会再次使用它，但不会用于另一个状态机。
另请参阅请确认：Windows Workflow Foundation 现在是一匹值得支持的好马吗？
We use WF in our production enviorments. We have 6 different workflows that can be run. These split into 3 statemachine and 3 sequences. I would use it again in some circumstances, but I would not in others. I would claim that the statemachine part of the workflow was tacked on the end quickly, I'm not sure it a core part of the workflow all the way through design.
I would use workflow again for short running processes like quotes or transforming things before sending them to supliers that kind of thing.
I would not want to do it again for a long running statemachine - mainly because there is not a built in WF upgrade process so we ended up writing our own. There are also a lot of concepts to get your head around (affectionalty known as gypsy curses with in our development team).
I would also be slightly concerned about performance: our App server is currently running flat out (ok I am restarting 8000 workflows at the moment). This is especially a problem if you integrate it directly into WCF using the (.NET 3.5) send and recieve activities - there are some properly crazy config settings you have to set to allow it run multiple workflows at once.
Anyway, as I said: it is useful, I would use it again, but not for another statemachine.
Also see Please confirm: Is Windows Workflow Foundation a good horse to be backing right now?
大多数人都对工作流程赞不绝口，但我发现它们引入了不必要的代码复杂性和维护问题。 它们适用于特定类别的问题。 除此之外，他们需要大量的代码管道和维护噩梦。
Most people say all the good things about Workflows but I have observed that they introduce unnecessary code complexity and maintenance problems. They are suitable for a particular class of problems. other then that they need a lot of code plumbing and maintenance nightmares.