决定用于web项目的工具（SharePoint、工作流、ASP.NET）

我有一个关于我们计划开发的项目的问题

我将从描述这个项目开始，稍后我将展示我看到的解决这个任务的可能方法。我希望你能给我你的意见

主要有两个部分： 第一部分：

在我们的组织中，我们希望创建一种中央访问点，用户将在这里登录（仅一次），并从那里获得指向我们提供的不同服务的链接（取决于他们的角色）

方法： 我们使用ActiveDirectory来管理我们的用户，所以我们想用SharePoint基金会创建这个中央访问点。 你认为这是一个好方法吗

第二部分：

我们拥有SharePoint服务，用户可以共享文档和其他web应用程序。其想法是将所有这些集成到前面描述的中央接入点

到目前为止，一切顺利。现在我们被要求开发一个新的web应用程序。此应用程序也是我们服务的一部分；因此，需要将其集成到中央接入点中

应用程序描述：这将是一个应用程序，由3个不同角色的人员填写一些信息（按特定顺序，第一个角色填写，然后是第二个角色，然后是第三个角色）。填写信息的每个步骤后，下一个人将通过电子邮件通知他/她的部分已准备好填写。要填写的信息是对产品的评估（仅供参考）

组织的经理们还希望有一个控制面板，以便他们能够对应用程序的使用进行统计。在那里，他们可以看到待评估、每年评估、每个角色评估

方法：

正如您将看到的，我们的主要疑问在于使用

SharePoint站点ASP.NET页面（C#）

工作流（SharePoint Workflow或just Workflow Foundation）使用内部代码中的某些标志来控制工作流

我们正在考虑：

1-提出我们希望使用SharePoint作为“中央访问点”的想法。我们将创建一个SharePoint web应用程序（如果可能，使用SharePoint Designer 2010）。并将SharePoint工作流应用于该流程

2-创建ASP.NET网站并将其导出为web部件，我们可以将其集成为SharePoint中的应用程序。试着在上面使用SharePoint工作流。（事实上，我们不知道该怎么做）

3-创建一个ASP.NET站点，忘记工作流工具，因为我们的工作流非常小，而且是连续的，并且在代码中用一些标志控制所有这些

你认为我们目前的想法如何？你能给我们提些不同的建议吗

非常感谢你的帮助

---

我们的SharePoint是免费版本SharePoint基金会。

< P>选项1听起来最适合您的方法，只要Web应用程序不想成为完全超出SharePoint界限的东西。

就基本工作流支持而言，SP基础不应成为问题。有关中工作流支持的更多详细信息，请参阅本文

---

选项2和3听起来有点冒险，而且会涉及大量定制代码，SP将为您提供OOTB。

选项1中是否可以将表单的各个部分限制为不同的角色（每个角色只能填写他/她的部分；但他们可以阅读其他部分）？我们如何关联工作流？我们只知道如何处理文档为什么不创建三个单独的表单并将它们与您的广告角色关联？这将使解决方案更易于管理。工作流的工作方式与您使用文档的工作方式相同。您是否有任何来源可以让我看到工作流使用的示例？请参考此，以获取起点。