ASP.NET Web 门户的多种解决方案布局？

Question

在工作中，我们开发了一个自定义的 ASP.NET Web 门户（这与 iGoogle 非常相似）。我们有“应用程序”（独立的大型网络表单）和“模块”（类似于 Google 小工具）。

目前，我们使用单一解决方案模型。现在，我们有：

• 3 个核心项目
• 60个应用项目
• 80 个模块项目

为了减少项目之间的复制和粘贴，我们将把通用功能（数据访问、业务逻辑）分解到单独的项目中。我还想介绍单元测试，这将进一步增加项目的数量。

我们已经到了 Visual Studio 对项目数量感到窒息的地步。我们通常只加载 3 个核心项目，然后加载我们正在处理的任何应用程序/模块的项目。

不同的解决方案结构会帮助我们吗？我们的项目数量只会增加。

一般来说，一个应用或模块只引用 3 个核心项目。很快，应用程序/模块可能会开始引用数据访问/业务逻辑项目。但一般来说，应用程序和模块之间不会进行引用。

所以回顾一下，当有许多项目使用少量核心项目时，解决方案结构的最佳实践是什么？

Answer 1

我们基于强大的模块化原则开发了类似的 ASP.NET Web 门户。我们支付的税是很多 Visual Studio 项目。 有一个包含所有模块、网站、单元测试等的单一主解决方案，但该解决方案通常无法在具有少量 RAM (

我们有通用的基础架构代码（约 10 个项目）和业务模块项目。单个业务模块由处理业务需求某些方面的所有项目组成，例如订单、客户管理、分销……业务模块通常有：

• ASP.NET Web 应用程序项目（成为 Shell 模块网站的子网站），
• 领域模型组装（无依赖的类库）+接口组装，
• 域模型的 OR/M 适配器（我们使用实体框架和 NHibernate），
• 带有演示器、控制器、视图模型等的前端组件...，
• 带有模块业务服务和DTO+接口组装的后端组装，
• 单元测试程序集，
• 其他程序集（如 Silverlight 组件、MSQM DTO 等）。

我们使用 SLNTools Filter (http://slntools.codeplex.com/) 从主解决方案中过滤掉单个业务模块 VS 解决方案。所以我们有解决方案 OrdersModule.sln、CustomersModule.sln 等。每个这样的解决方案都有共同的基础设施项目（~10）和模块项目（~10-15）。 SLNTools 过滤器自动包含所有依赖项目，因此很容易创建新的过滤解决方案。