Sharepoint工作stream程与Windows工作stream程

SharePoint中的工作流程是使用Windows Workflow Foundation实现的，所以它们没有什么不同，但仍然有一些事情需要注意。

SharePoint是一个Windows Workflow主机，所以如果您同意SharePoint团队做出的决定，则无需实施自己的主机，这很好：

• 工作流实例在内容数据库中保存
• 与用户的沟通是通过SharePoint任务
• 每个工作流实例都绑定到列表/库项目
• 跟踪没有执行

如果这些选择是你喜欢的，那么一定要使用SharePoint工作流程。

如果没有，那么实现你自己的主机，并做出自己的决定。

他们是一样的东西。 当前的Windows工作流引擎是为SharePoint创建的。

现在应该注意的是，工作流引擎将会随着.NET 4.0的发布而被彻底改变。 我不知道具体情况，但是我被告知差异是显着的。 我想假设这将在Sharepoint 2010中使用，但我没有任何有关的信息。

这里是描述4.0中升级的链接 。

您尚未指定是在SharePoint中构建自定义编码的应用程序还是通过浏览器配置开箱即用的解决方案。 无论哪种方式，以下是SharePoint中工作流的几个选项。

1. 使用内置于SharePoint中的原生工作流，并可以从任何列表轻松访问。 他们非常基本（主要是简单的审批，只需一到两个步骤），但他们会很快启动并运行，而且都可以通过浏览器完成。
2. 使用SharePoint Designer构建稍微复杂的工作流程。 这将使您能够访问条件逻辑（即根据列表值进行工作流程路由）和无限制的步骤以及许多其他功能，从而允许您在流程中引入更多的逻辑。 缺点是你必须使用SharePoint Designer，坦率地说，这可能是一个真正的痛苦。
3. 在WF中定制您的工作流程代码。 Windows Workflow是基础框架之上的前两个选项的基础。 这种方法的主要区别在于，您不仅限于浏览器或SPD的功能。 不足之处在于，这变成了一个更复杂的过程（虽然承认工作流程可能会更复杂），你必须经历对SharePoint的编码，封装部署，发布等等的艰难工作。

在易用性和功能性方面，我发现最好的平衡就是按照我提供的顺序尝试通过上面的列表，如果你肯定不能按照当前的要求来实现这个需求，那么只有进入下一个选项。

这基本上是相同的技术。 如果你知道一个，你可以轻松地工作/切换到另一个。

当您将SharePoint dll添加到解决方案时，您将获得一些可用于工作流的特定SharePoint“活动”。 （创建任务，…）

您的SharePoint server将充当您的工作流的主机。

在SharePoint中部署工作流程的最佳方式是使用SharePoint功能。 这告诉SharePoint什么dll（组件）使用和哪个（输入）页面显示。

作为输入页面，您可以使用简单的.net aspx页面或信息表格。 两者都需要一些试验和错误才能掌握。

SharePoint只是使用Windows工作流基础（WF）作为其工作流引擎。 WF本身就是一个通用的工作流引擎。

为了使用WF，你必须实现一个宿主进程来执行工作流程，并配置它以便将实例持久化到数据库等等（现在大多数人使用WCF服务作为工作流主机，参见这里或这里 ）。

SharePoint提供了已配置的所有内容，并实现了自己的工作流程主机，因此您可以开始使用开箱即用的工作流程。 除此之外，它还带有特定于SharePoint的自定义活动和其他好东西。

正如其他答案中所述，它们与使用Windows WOrkflow Foundation相同。 也就是说，在通过Sharepoint设计器创建的工作流程中，需要记住一件重要的事情：它们不是“可移植的”，这意味着您可以创建一个绑定列表a，然后将列表保存为一个模板，然后创建基于该模板的另一个列表，工作流将无法正常工作（因为它仍然引用原始列表的id（guid），所以您重新绑定了它。