创建ASP.NET门户和模块的最佳实践是什么？

Question

最近，我们机构的一个部门的一位代表找到了我们的开发团队，希望找到一个基于web的解决方案来帮助他们完成工作流程。几周后，该部门的另一个人找到我们，讨论另一个完全不同的工作流程的解决方案。然后在那之后。另一个来自不同人的来自同一部门的请求。

在我们为各种请求收集需求的过程中，我们注意到这些请求的核心方面之间存在一些共同点。在项目之间，一些用户是共享的，而另一些则不是，一些用户的角色在进程之间改变，2个应用程序访问相同的数据，其中2个应用程序访问客户端数据。单个请求远不是微不足道的。

现在，我们正在考虑为这个部门创建某种类型的门户。门户将作为各种模块/工具的主要入口点，我们将从它们中提供这些模块/工具。除此之外，还将有一个核心数据库来存储应用程序之间的公共数据，然后特定于模块的数据将驻留在各自的数据库中。

我的问题是，在asp.net、IIS6、MSSQL2005环境中开发这样一个门户的最佳方式是什么？我在考虑在IIS中创建一个应用程序池，用于所有模块和门户。将门户和每个模块创建为单独的web应用程序，并将模块部署到门户应用程序下的子文件夹中。门户只需要提供到各种可用模块的链接。这有意义吗?还是有更好的方法？我知道如果我们有足够的资源购买和设置SharePoint，SharePoint将是一个很好的解决方案，但我们没有。

Answer 1

“我知道如果我们有足够的资源购买和设置SharePoint，SharePoint将是一个很好的解决方案，但我们没有。”

如果你指的是Sharepoint services，根据你需要的版本和你已经拥有的版本，可能不会涉及任何购买。还可以检查@balexandre提到的DotNetNuke。

如上所述，如果您采用自定义路线，我将更多地关注于库重用而不是部署方面，以共享核心。拥有主站点+两个应用程序文件夹是很好的，但如果更简单的库调用可以在您的场景中工作，那么不要让它让您进入跨应用程序调用。

不要直接从这两个应用程序访问核心数据库。使用业务级别的操作来访问数据，并定义一个非常清晰的边界/使用非常简单的操作。边界非常重要，如果您试图在低级别同时对3个项目进行建模，这只会意味着不必要的复杂性/在分析期间和结果产品中都是如此。当同时考虑3个项目时，保持其高度，因为边界涉及的操作应该是高度的。这就是它的实际工作方式，如果你后来得到了其他应用程序/项目-否则你会发现你自己与5+产品的信息和非常令人头疼的决策。

Answer 2

我在考虑在IIS中创建一个应用程序池，用于所有模块

也许吧。我并不是说这很糟糕--这只是一个非常低层次的细节，听起来你有更大的事情要做。

我没有使用过DonNetNuke，我知道有一家公司使用它的多租户模块。如果系统是工作流密集型系统，您可能需要研究工作流系统- K2 BlackPearl在微软影响的市场中已经相当成熟。如果你还没有发现它(并且你不打算使用像DNN这样的东西)，那么微软企业库是必备的(参见：MS Patterns & Practices和CodePlex)。

其他需要考虑的问题：

• 你想要有一个好的框架来处理所有(真正的)常见的东西(日志记录等)。
• 将不同部门的区域分开是明智的；我的方法是为每个部门创建一个项目，再加上一个门户项目。框架将再次分离。
• 对数据进行建模-即使它在白板上。理解数据(什么是共享的，什么不是，它从哪里来，谁在使用它)是一个很好的important.
• When，它看着重用:记住在正确的层次上使用它。仅仅因为你写了一个特定的UI并不意味着你必须为它编写特定的BL和/或DAL。
• 使用抽象和依赖注入来分隔各层(特别是BL和DAL)。
• 使用Interface Segregation Principle来保持系统的verticla部分的分离。

Answer 3

我想说一件简单的事情，这样你就不会在创建现有的东西时感到头疼……

对于ASP.NET门户和模块，请使用DotNetNuke

它是开源的，所以你已经有了所有的代码...在它的基础上进行构建！