Visual Studio 2008 解决方案中的最佳项目数是多少？答案

【问题标题】：What is the optimum number of projects in a Visual Studio 2008 solution?Visual Studio 2008 解决方案中的最佳项目数是多少？
【发布时间】：2008-12-04 02:36:01
【问题描述】：

Visual Studio 2008 解决方案中的最佳项目数是多少？

我们有一个 Visual Studio 2008 解决方案，目前约有 50 个项目。随着解决方案中的大部分项目由主应用程序的插件程序集组成，它可能会继续增长。

如果在一个解决方案中看起来“项目太多”，那么您将如何确定应该在一个解决方案中将哪些项目组合在一起？鉴于我们在一个解决方案中有大约 50 个项目的示例，其中大部分项目是插件并且插件的数量可能会增长，那么解决方案应该如何构建？所有插件都应该放在自己的解决方案中吗？当插件解决方案中的插件数量达到“太多”的神奇数字时，组织应该如何改变？

我们对解决方案中的这么多项目没有任何问题...加载速度快，构建速度快，使用合理的内存量，并且不会导致 VS2008 崩溃或与任何 VS2008 发生碰撞错误。

我查找了 Microsoft 的文档（似乎没有），Google 搜索了从“每个项目都有自己的解决方案”到“将所有项目放在一个解决方案中”的 yeild 建议。这两种极端似乎都是荒谬的。我正在中间寻找一些合理的指导。

在 Stackoverflow 上还有其他与您看到的 maximum 相关的问题。这与最佳状态不太一样。

【问题讨论】：

标签： visual-studio

【解决方案1】：

我会说您系统上的每一层至少需要一个项目。如果您需要更多项目，可能是设计问题。这意味着您可以“过度”设计或“不足”设计应用程序。

我现在使用以下层：

DataLayer - 负责底层数据结构（数据库）。在此项目中具有 LINQ 和部分类的最新案例。

接口 - 所有接口都有一个层，这有助于可扩展性，而不必依赖其他一些层来使用这些接口。

逻辑 - 这定义了自己，业务逻辑

GUI / Front - 图形用户界面（代码）

这些层是最小的其他层，可能是本地化和其他可能增长的项目。

但是比起在许多项目中使用，更简单的目录和命名空间！

【讨论】：

没那么简单。层可以（并且通常应该）分解为组件，即数据层可能具有抽象（通用）部分和一个或多个具体实现。拥有一个接口程序集还可能导致向系统的未使用部分添加依赖项。

【解决方案2】：

这类似于诸如“我应该在一个班级中有多少个函数？”之类的讨论。和“是否应该在自己的 .cs 文件中定义每个枚举？”。

我很想知道您的每个项目有多少类。您可以将您的课程、项目和解决方案视为组织单位。它们可以让您的生活更轻松，并让您（和您的团队）将整个项目分解为可管理的概念块。

如果 VS2008 没有抱怨，并且您和您的开发人员在一个解决方案中处理 50 个项目没有问题，那么我不会担心。

也就是说，这听起来确实是一个相当大的数字 - 但我们对您的整个代码库的大小一无所知，因此很难进一步评论。

【讨论】：

Stack Overflow 有said that they：只有 9 个项目，其他系统有 100 个。项目这么少的原因是编译速度非常快，这需要在一开始就进行规划。在一台计算机上编译需要 10 秒。 考虑到这一点，从编译速度的角度来看，50 个项目是非常理想的。

【解决方案3】：

显然，当您达到 500 时，您就会开始考虑“太多”，即使管理它也变得不切实际。

我可能建议您分析“真正构成我的应用程序的内容”并将其打包为一个解决方案。插件很少被视为基本应用程序的一部分，而是基本功能的附加组件。

如果应用程序在没有某些插件的情况下将不再有用，则将这些插件包含在基本解决方案中。

其他插件可能按流派分组...很像 iPod 上的播放列表。每个插件在更一般的层面上实现了什么？（这些显然是修辞问题）我会将插件分组到自然组中 - 很像 PhotoShop 插件，因为它们在菜单上分组。即它们是否会影响 3D、是否会影响颜色、是否会影响几何效果、是否会影响失真等。

【讨论】：

【解决方案4】：

当我看到速度变慢时，我倾向于创建一个解决方案，它引用依赖项目的构建版本（程序集）而不是项目文件（对于我不需要查看源代码的任何项目）。我只为我正在处理的项目开放源代码——当然没有人需要同时处理 50 个项目的源代码。

如果您已经在引用依赖程序集而不是源代码，那么我认为这只是一个问题或组织偏好（以您最容易理解和维护的方式组织）。

【讨论】：