最近，我们的开发团队与我们机构的一个部门的代表联系，寻找基于Web的解决方案来帮助他们完成工作流程。几个星期后，该部门的另一个人向我们询问了另一个完全不同的工作流程解决方案。然后是......来自不同人的同一部门的另一个请求。
在我们收集各种请求的要求中，我们注意到请求的核心方面之间存在一些共同点。在项目之间共享了一些用户，有些用户没有共享，有些用户角色在进程之间发生了变化，2个应用程序访问了相同的数据，其中2个访问了客户端数据。个人要求远非微不足道。
现在，我们正在考虑为该部门创建某种门户网站。门户网站将作为我们将从中提供的各种模块/工具的主要入口点。除此之外，还有一个核心数据库，用于存储应用程序之间的公共数据，然后模块特定数据将驻留在各自的数据库中。
我的问题是，在asp.net，IIS 6，MSSQL 2005环境中开发这样一个门户的最佳方法是什么。我想在IIS中创建一个应用程序池，用于所有模块和门户。将门户和每个模块创建为单独的Web应用程序，并将模块部署到门户应用程序下的子文件夹。门户网站只需提供指向各种可用模块的链接。这有意义还是有更好的方法？我知道如果我们有资源购买和设置SharePoint，SharePoint将是一个很好的解决方案，但我们没有。
答案 0 :(得分：1)
我想要有一个应用程序池 在IIS中创建用于所有的 模块
也许。我不是说这很糟糕 - 它只是一个非常低级别的细节，听起来你有更大的鱼要炸。
我没有使用过DonNetNuke，我知道有一家公司使用它拥有的多模块模块。如果系统是工作流程密集型的，您可能需要查看工作流程系统 - K2 BlackPearl在受Microsoft影响的市场中已经相当成熟。如果你还没有发现它（并且你不会使用像DNN这样的东西）那么微软企业库是必须的（参见：MS Patterns & Practices和CodePlex）。
需要考虑的其他要点：
答案 1 :(得分：1)
“我知道SharePoint会很好 解决方案，如果我们有资源 购买并设置SharePoint，但是 我们没有。“
如果您的意思是Sharepoint services，根据您需要的版本和已有的版本，可能不会涉及任何购买。同时检查DotNetNuke为@balexandre。
上面说过，如果你要去自定义路线，我会更多地关注库重用而不是部署方面来共享核心。拥有主站点+ 2个应用程序文件夹是好的，但如果更简单的库调用适用于您的场景，请不要让它进入跨应用程序调用。
不要直接从2个应用访问核心数据库。使用业务级别操作来访问数据，并使用非常简单的操作定义非常清晰的边界。边界非常重要，如果您尝试同时对低级别的3个项目进行建模，它将只表示在分析期间和最终产品中不必要的复杂性。在同时考虑3个项目的时候，保持高度和边界所涉及的操作一样。这是它实际工作的方式，如果你以后获得其他应用程序/项目 - 否则你会发现你自己的决定有5个以上的信息产品和非常头疼。
答案 2 :(得分：0)