Visual Studio 2008解决方案中的最佳项目数是多少？
我们现在有一个Visual Studio 2008解决方案，大约有50个项目。它可能会继续增长，因为解决方案中的大部分项目都包含主应用程序的插件程序集。
如果在一个解决方案中看起来“太多项目”，那么您将如何确定哪些项目应该在解决方案中组合在一起？鉴于我们在一个解决方案中大约有50个项目的示例，其中大部分项目是插件，插件数量可能增长，应该如何构建解决方案？是应该将所有插件放在自己的解决方案中？当插件解决方案中的插件数量达到“太多”的幻数时，组织应该如何改变？
我们对解决方案中的这么多项目没有任何问题......它加载速度快，构建速度快，使用合理的内存量，并且不会导致VS2008崩溃或碰到任何VS2008错误。
我一直在寻找微软的文档（似乎没有任何内容），谷歌搜索“每个项目都有自己的解决方案”的建议，“将所有项目放在一个解决方案中”。两种极端似乎都是荒谬的。我正在中间寻找一些合理的指导。
Stackoverflow上有与您见过的maximum相关的其他问题。这与最佳状态并不完全相同。
答案 0 :(得分：4)
我说你的系统每层至少需要一个项目。如果您需要更多项目，可能是设计问题。意思是你可以“Over”-design或“Under” - 设计应用程序。
我现在使用以下图层：
DataLayer - 负责底层数据结构（数据库）。在最新的情况下，在这个项目中有LINQ和部分类。
接口 - 为所有接口提供一个层，这有助于扩展，而不必依赖其他一些层来使用这些接口。
逻辑 - 这定义了自己，业务逻辑
GUI / Front - 图形用户界面（代码）
这些图层是可能的最小其他图层，可能是本地化和可能增长的其他项目。
但是rahter简化了目录和命名空间，而不是使用很多项目！
答案 1 :(得分：3)
这类似于诸如“我应该在课堂上有多少功能？”之类的讨论。并且“每个枚举应该在自己的.cs文件中定义吗？”。
我很想知道你的每个项目有多少个类。您可以将您的课程，项目和解决方案视为组织单位。它们可以让您的生活更轻松，并允许您（和您的团队）将整个项目分解为可管理的概念块。
如果VS2008没有抱怨，并且您和您的开发人员在一个解决方案中对50个项目没有任何问题，那么我就不用担心了。
也就是说，它确实听起来像一个相当大的数字 - 但是我们对整个代码库的大小一无所知，因此很难进一步评论。
答案 2 :(得分：0)
显然，当你达到500时，你开始看“太多”，即使管理它也变得不切实际。
我可能会建议您分析“我的应用程序的真正构成”并将其打包为单一解决方案。插件很少被视为基本应用程序的一部分，而是基本功能的附加组件。
如果应用程序在没有某些插件的情况下不再有用，那么请在基础解决方案中包含这些插件。
其他插件可能会在Genre上分组...就像iPod上的播放列表一样。每个插件在更一般的层面上实现了什么？ （这些都是明显的修辞问题）我会将插件组合在一起组成自然组 - 就像PhotoShop插件在菜单上组合一样。即它们是否会影响3D，它们是否会影响颜色，是否会影响几何效果，是否会影响失真等等。
答案 3 :(得分：0)
当我看到速度变慢时，我倾向于创建一个解决方案，该解决方案引用了依赖项目的构建版本（程序集）而不是项目文件（对于我不需要查看源代码的任何项目）。我只打开我正在处理的项目的来源 - 当然没有人需要同时处理50个项目的来源。
如果您已经引用了依赖程序集而不是源代码，那么我认为这只是一个问题或组织偏好（以最容易理解和维护的方式组织）。