我们需要构建几个需要相当高级的工作流功能的应用程序。计划是将数据存储在 SQL Server 中，使用 Windows Workflow Foundation 作为工作流引擎，并使用 Flex 或 Silverlight 等 RIA 技术构建前端。
我们已经设置了 Sharepoint 2007，并且我们中的一些人（包括我）有一些创建自定义 Sharepoint 工作流的经验，这些工作流可以处理 Sharepoint 列表中的数据。
我的问题是，将 Sharepoint 用于工作流程是否有意义，而实际数据存储在 Sharepoint 之外的单独数据库中？我们需要 Sharepoint 的任务、身份验证和电子邮件功能，但是我们的数据模型有点复杂，所以我们宁愿不将数据存储在 Sharepoint 中。我们宁愿不要从头开始使用 Workflow Foundation，因为 Sharepoint 已经为我们提供了我们需要的 90% 的功能。
有什么想法/建议吗？
我认为这是将 SharePoint 用作平台的一个很好的示例。我没有看到以您描述的方式使用它的任何概念问题。我将 SharePoint 视为一个开发平台。您可能要记住的一件事是，如果您想让工作流继续处理单独数据库中发生的事件，您可能必须更新例如来自外部程序的工作流任务项。
您的用例非常合适，并且 SharePoint 为其增添了巨大价值。我强烈建议使用 SharePoint 来托管您的工作流。
我开发了许多 SharePoint 托管的 WF 工作流，我遇到的唯一真正的问题是调用长时间运行的 Web 服务（异步操作），因为 SharePoints WF 主机对其可以侦听事件的外部提供程序的类型有一些限制。
我开发的解决方案（起初有点破解，但最终对我的客户有一些价值）是创建一个位于 SharePoint 外部的服务代理 (WCF)，并将调用路由到远程服务并等待他们的回应。在进行该异步调用的同时，并行活动将创建与异步操作关联的 SharePoint 任务。然后 WF 将在 OnTaskCompleted 活动上停止，这会导致 WF 资源被释放并将状态持久保存到 SQL。由于长时间运行的操作会返回状态更新或完成通知，外部服务将更新相关的 SharePoint 任务。一旦任务被标记为完成，WF 就会脱水并继续执行。这种方法的巧妙之处在于，我可以创建一个仪表板，显示在 SharePoint 之外进行的所有长期运行进程的状态。最后，我将所有这些东西打包成一个复合活动，这样它就不会弄乱我漂亮的工作流程图。
我同意 SP 可以提供一个不错的 WF 引擎，但让我问一下……您是否在 SharePoint 中存储任何内容？（任务、数据源等）
我问是因为运行自己的 WF 引擎可能同样容易（而且更合适）。如果您正在运行所有原生 WF 功能，并且只需要一个引擎，您可以编写一个可以启动工作流的快速控制台应用程序。
如果您将 SP 用于WF 以外的任何东西，那么我绝对同意使用 SP。
SharePoint 非常适合这种情况。我建议使用业务数据目录 (BDC) 来访问外部数据源。它主要通过使您的数据源可搜索以及提供 OOB Web 部件以通过主子关系、过滤和丰富的 API 显示数据来提供巨大的好处。
我会提醒不要让工作流过于复杂，而是使用较小的工作流、InfoPath 和用户操作将过程分解为多个阶段，以促进整个过程。这就是 SharePoint 真正发挥作用的地方，因为您可以使用仪表板（如果它对您的方案有意义）以及协作、批准......将流程阶段的可见性插入到组织中的其他人身上。这样的例子不胜枚举。