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

Question

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

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

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

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

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

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

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

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

Answer 1

我们基于强大的模块化原则开发了类似的 ASP.NET Web 门户。我们缴纳的税款是很多 Visual Studio 项目。有一个包含所有模块、网站、单元测试等的主解决方案，但该解决方案通常无法在 RAM 量较小(<= 4 GB)的计算机上日常使用。

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

• ASP.NET Web 应用程序项目(成为 Shell 模块网站的子网站)，
• 领域模型组装(无依赖的类库)+接口(interface)组装，
• 用于域模型的 OR/M 适配器(我们使用 Entity Framework 和 NHibernate)，
• 带有演示器、 Controller 、 View 模型等的前端组件，
• 带有模块业务服务和DTO的后端组装+接口(interface)组装，
• 单元测试程序集，
• 其他程序集(例如 Silverlight 组件、MSQM DTO 等)。

我们使用SLNTools Filter(http://slntools.codeplex.com/)从主解决方案中过滤掉单个业务模块VS解决方案。因此，我们有解决方案 OrdersModule.sln、CustomersModule.sln 等。每个此类解决方案都有通用基础设施项目 (~10) 和模块项目 (~10-15)。 SLNTools Filter 自动包含所有相关项目，因此可以非常轻松地创建新的过滤解决方案。