Visual studio 关于何时启动新解决方案或何时仅向现有解决方案添加新项目的指南

在VisualStudio中，新项目何时属于当前正在处理的解决方案，何时应将项目移动到其自己的解决方案中？大型解决方案与小型解决方案的优缺点是什么？在做出这个决定时，我应该考虑什么？我们选择的项目方法对方法有任何影响吗？这只是个人喜好吗

例如，我们目前正在为我们的客户构建一个新产品，它由一个Silverlight应用程序、一个ASP.NET MVC报告控制台和一个ASP.NET MVC管理控制台组成，这些控制台都与现有的客户机数据数据库和一个新的共享应用程序数据库相关联。目前，该项目的VisualStudio解决方案包括所有内容—Silverlight项目、Reporting网站项目、Admin网站项目和两个WCF服务应用程序，用于对每个数据库进行数据访问。是否应将其中任何/所有内容分解为其各自的解决方案

我希望我以一种有意义的方式阐述了这个问题。我对我的思维过程应该是什么感到困惑。

注意事项：

• 依赖关系-如果项目相互依赖，那么将它们放在同一个解决方案中有助于确保更改扩散到依赖项目
• 性能-我有几个由许多项目组成的解决方案，诚然，加载和构建整个解决方案需要很长时间
• 便利性-显然，将所有项目放在一个解决方案中比跨多个打开的项目导航更方便。同时，多个项目可能会使解决方案资源管理器变得混乱

其他想法：

• 如果需要并行调试两个项目，例如一个客户机/服务器对，那么两个解决方案允许您在VisualStudio的单独实例中调试这两个项目
• 考虑到您的项目可能独立于您的解决方案而改变。例如，更改项目名称可能意味着必须更新多个解决方案和引用

然而，我并不认为这只是个人喜好。根据内容的不同，所采用的方法可能存在一些显著差异

还有什么我没有考虑的吗

---

下面是MSDN的一篇文章，讨论了构建项目和解决方案的推荐方法。值得一读。

当解决方案封装了不同的责任领域时，我会说将它们分开。文档管理系统中的示例由一个部门处理，但安全性由另一个部门控制。此外，解决方案的工作人员数量应与解决方案的规模保持一致。让太多人在一个解决方案上工作充其量也会很困难。最后，我想说，当您想与其他项目或解决方案共享功能时，我会将其分解为自己的解决方案