ASP.NET Web Portal的多解决方案布局？

Question

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

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

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

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

我们已经达到了Visual Studio扼杀项目数量的程度。我们通常只加载3个核心项目，然后加载我们正在处理的任何应用程序/模块的项目。

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

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

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

Answer 1

我们基于强大的模块化原则开发了类似的ASP.NET Web门户。我们支付的税是很多Visual Studio项目。 有一个主要的解决方案，包括所有模块，网站，单元测试等等，但这种解决方案通常不可行，每天在具有少量RAM（<= 4 GB）的计算机上工作

我们有共同的基础设施代码（~10个项目）和业务模块项目。单个业务模块由处理业务需求的某些方面的所有项目组成，例如，订单，客户管理，分销......业务模块通常具有：

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

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