Windows Workflow Foundation 在哪里使用？
WF是用在用户界面还是业务层？如果在UI层，那么在业务层编码的人是否还需要使用或学习它？
Is WF used at user interface or business layer? If at UI layer, then does someone coding in business layer even need to use or learn it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
克里斯提供了一个很好的答案，所以我会采取不同的策略。工作流程实际上与逻辑不同。工作流通常是逻辑的组合，这使得它们成为整体的补充贡献者。业务组件很好地封装了单个业务规则或行为，而工作流则由多个业务组件、规则和行为组成，以满足更大、运行时间更长的业务流程的需求。
工作流程可以适应任何地方，满足 UI、业务甚至数据层的流程需求。如果您最终使用 WF，我强烈建议您培训您的一般开发人员，以便获得广泛的知识和理解。尽管具有可视化方面，WF 仍然需要一些低级编码来构建活动库，以便工作流创建者和维护者可以使用。
编辑：
是否使用它取决于您。一般来说，大型项目会使用 WF，因为 WF 提供了宝贵的投资回报。 WF 比简单地编写代码更难使用。学习曲线相当陡峭，需要采用不同的方式来解决业务问题，并且需要特殊的技能。向 WF 提供代码会增加开销，因为您必须编写可能在工作流中使用的活动以及构建工作流本身。
如果您认为在您的小型项目中使用 WF 将提供宝贵的投资回报，那么就去做吧。您不仅需要收回培训、基础设施实施和部署的初始成本，还需要比简单地编写代码来解决手头的问题提供长期、切实的成本节省。我怀疑 WF 是否会提供这样的小项目的投资回报率。对于较大的项目或单个大公司的多个集成项目，比较小的项目更容易实现投资回报率，这就是为什么像 WF 这样的工作流平台通常只在这种规模上使用。
Chris offered a great answer, so I'll take a different tack. Workflow is really not the same as logic. Workflows are generally compositions of logic, which makes them a complimentary contributor to the whole. Where a business component nicely encapsulates a single piece of business rules or behavior, a workflow composes multiple business components, rules, and behavior to meet the needs of larger, longer-running business processes.
Workflows can fit anywhere, filling process needs for UI, business, and even data layers. If you do end up using WF, I highly recommend that you train your general development staff, so that there is broad knowledge and understanding. Despite having a visual aspect to it, WF still requires some low-level coding to build up a library of activities and such that workflow creators and maintainers will use.
EDIT:
Its up to you whether to use it or not. Generally, WF is used by larger projects, because WF offers a valuable return on investment. WF is harder to use than simply writing code. There is a fairly steep learning curve, requires a different way of approaching business problems, and requires special skill sets. Providing code to WF adds overhead, as you have to write activities that may be used in workflows, as well as build the workflows themselves.
If you think that using WF for your small project will provide a valuable return on investment, then go for it. You will need to both recoup the initial costs of training, infrastructural implementation, and deployment, as well as providing long-term, tangible cost savings over simply writing code to solve the problems at hand. I would be doubtful that WF will offer a small project such ROI. For larger projects, or multiple integrated projects for a single large company, it is much easier to realize that ROI than it is with smaller projects, which is why workflow platforms like WF are usually only used on that scale.
WF是业务层的接口。
工作流是一种通过将预定义的活动链接在一起来编写程序的声明性方式，而不是编写代码行的命令式编程模型。此外，您还有许多图形工具可以帮助您编写工作流程。例如 Black Pearl、K2 和 Sharepoint Designer。
它们被广泛使用并且非常值得学习。我开始在 sharepoint 和 ms crm 中使用。我现在总是寻求工作流程来解决我的常见问题。
这里有一些链接：
mirosoft msdn.microsoft.com/en-us/netframework/default.aspx
Wkik：http://en.wikipedia.org/wiki/Windows_Workflow_Foundation
WF is the interface to the buisness layer.
Workflows are a declarative way of writing programs by linking together pre-defined activities rather than an imperative programming model of writing lines of code. IN addition, you have many graphical tool that allow you to wrtie workflows. shuch as black pearl, K2 and sharepoint designer.
They are very much used and are well worth learning. I started using then in sharepoint and ms crm. I now always look to workflows to solve my common problems.
here are a few links:
mirosoft msdn.microsoft.com/en-us/netframework/default.aspx
Wkik: http://en.wikipedia.org/wiki/Windows_Workflow_Foundation
WF 大多数情况下都被理解为势在必行——一系列按时间顺序排列的事件。
但是，如果您深入研究，您可以以不同的方式组合活动。一个很好的例子是基于状态的工作流程，通常在演示 WF 时也会显示。 WF 允许您将工作流程置于空闲模式：一旦发生外部事件，就会保留并重新加载当前状态。因此，工作流可用于跟踪长时间运行的交互，其中系统必须等待某些外部进程结束或某些用户与系统交互。
我想说 WF 在 UI 上下文中不会很有用。它们更适合作为后端模块来表达集成多个具有及时变化趋势的服务的流程。
但从我的角度来看，值得注意的是 WF 是版本 1 产品：有许多尴尬的事情可能会引导您编写难以维护的代码，部分基础设施使用起来相当复杂，您可能会发现一些 API 不一致的地方 &那里。
如果您想将工作流程移植到下一代 WF，还有一个指南告诉您不应该做什么。
WF is mostly understood quite imperatively - a sequence of chronological events.
However, if you delve deeper you can combine activities in different ways. A good example are the state-based workflows that are usually also shown when presenting WF. WF allows you to put the Workflow into an idle mode: It's current state is persisted and reloaded once e.g. an external event takes place. As such, workflows can be useful in tracking long-running interactions where the system has to wait e.g. for some external process to end or some user to interact with the system.
I'd say that WF wouldn't be terribly useful in the UI context. They are better suited as a backend module to express processes integrating several services that have a tendency towards changing in time.
From my point of view, though, it is noticable that WF is a version 1 product: There are a number of awkward things that may guide you into code that is hard to maintain, parts of the infrastructure are quite complex to be used, you may find some API inconsistencies here & there.
There is also a guideline out there what you shouldn't do if you ever want to port your workflows to the next generation of WF.