如何使用解决方案/项目/文件夹组织大型项目？
我们正在做一个非常大的 VS 项目。
我们希望项目结构能够“提示”开发人员逻辑组件和设计。
为此，最好的方法是：
- 一个具有许多子文件夹和命名空间的项目
- 根据类的逻辑分组拆分为多个项目。将所有项目放在具有解决方案文件夹的同一解决方案中。
- 与 #2 相同，但有多个解决方案，而不是一个带有子文件夹的解决方案。
We are working on a very large VS project.
We want the project structure to "hint" developers on the logical components and design.
For this purpose, which is best:
- One project with many subfolders and namespaces
- Split to multiple projects based on logical grouping of classes. Have all projects in the same solution with solution folders.
- Same as #2 but have multiple solutions instead of a single with subfolders.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我的项目很大。
我们将每个“模块”分离在不同的程序集中，创建类库。像这样：
每个
类库都是解决方案Client.ProjectName或其他共享解决方案下的一个项目。文件系统如下所示：
共享客户端库立即位于
Client\Framework文件夹下，它旨在用于该客户端的所有项目。具体项目在解决方案中。我们还有一个名为Company的文件夹，其中保存可在任何客户的任何其他项目中使用的项目，它就像公司框架。我们使用的解决方案：
同一项目可以在多个解决方案中引用，因此您不一定需要创建所有这些解决方案。
通过这种格式，我们只需引用 DLL 就可以在其他项目中使用很多东西。如果没有这种结构，某些项目将无法在给定时间内完成。
My projects are huge.
We separate each "module" in different assemblies, creating Class Libraries. Something like this:
Each
Class Libraryis a project under the solutionClient.ProjectNameor under some other shared solution.The file system looks like this:
Shared client libs goes immediately under the
Client\Frameworkfolder, it is meant to be used on all projects for this client. Specific projects goes under the solution. We also have a folder calledCompanywhere we keep projects that can be used in any other project for any client, it is like the company framework.The solutions we use:
The same project can be referenced in multiple solutions, so you don't necessarily need to create all those solutions.
With this format we could use a lot of things on other projects simply referencing a DLL. Without this structure some projects wouldn't be possible in the given time.
我越来越喜欢使用带有关键域子文件夹的单一解决方案，并在其中添加项目。它很容易浏览，并且可以让您的开发人员大致了解什么在哪里。
如果任一解决方案中的组件之间的集成是松散的，则拥有多个解决方案非常有用，因此每个团队都有自己的工作解决方案，并针对其他团队解决方案中已发布的组件进行测试。
I have grown to prefer a single solution with subfolders for the key domains, and add the projects in those. It's easy to browse, and gives a rough idea to your devs as to what goes where.
Having multiple solutions is mostly useful if the integrations between the components in eigther solution is loose, so each team has its work solution, and tests against released components from the other teams' solution.
解决方案只是项目的容器，因此真正有问题的是项目的拆分。
我建议为每个主要功能区域使用不同的项目（也称为类库或程序集）。您可能仍然希望在每个项目中使用不同的命名空间，但是将主要功能区域分成不同的程序集将使每个程序集更小。因此，如果您需要在应用程序中仅使用一两个功能，则只需引用这两个项目，而不是引用一个大型项目。这将使较小的应用程序编译速度更快并且开销更少。
就解决方案而言，您可以按照自己的意愿组织它们，因为就像我说的，它们只是容器。您可能希望将它们全部放入一个解决方案中...或者可能将它们全部放入一个单独的解决方案中...或者可能将相关项目放入解决方案中。就我个人而言，我要么使用一种解决方案，要么对于大型项目，我使用“主”解决方案，这样我就可以轻松地一次编译所有内容，并使用单独的解决方案，这样我就可以单独处理项目。
Solutions are just containers for projects, so it's really the splitting of the projects that is in question.
I would recommend using a different project (AKA class library or assembly) for each major functional area. You may still want to use different namespaces within each project, but separating the major functional areas into different assemblies will make each assembly smaller. Therefore, if you need to use only one or two functions in an application, you only reference those two projects instead of the one massive project. This will make for smaller applications that compile faster and have less overhead.
In terms of solutions, you can organize those however you want because like I said, they are only containers. You may want to put them all in one solution...or maybe each in a separate solution...or maybe put related projects into solutions. Personally, I either use one solution, or for large projects, I use a "master" solution so I can easily compile everything in one shot and individual solutions so I can work on projects individually.
项目应该是您重用的“原子”。或者换句话说，项目是可重用代码的粒度。拥有相互依赖的项目是可以的，但每个项目都应该规划为对其自身功能有用。
解决方案就是您开发/构建/测试所需的任何项目集合。您可以有多个解决方案来指定不同的项目子集。
项目中的文件夹可能会有所帮助，但它们可能表明您的项目变得太大。
解决方案文件夹同样意味着您的解决方案可能变得太大。您能否将代码库划分为多个解决方案，每个解决方案都有有意义且可测试的输出工件？解决方案可以依赖于其他解决方案的（经过测试的）工件，就像它们依赖第三方库等一样。
您还应该考虑 VS 和解决方案项目如何映射到版本控制架构上的项目粒度以及您拥有的任何分支/合并策略。
A project should be your "atom" of re-use. Or to put it another way, projects are the granularity of reusable code. It's OK to have interdependent projects but each project should be planned to be useful for its own functionality.
A solution is just whatever collection of projects you need for development / build / test. You could have multiple solutions that specify different subsets of projects.
Folders within a project may help but they could be an indication that your project is getting too large.
Solution folders likewise mean your solution is probably getting too large. Can you divide your codebase into multiple solutions, each with a meaningful and testable output artifact? Solutions can depend on (tested) artifacts from other solutions, just as they do on third party libraries etc.
You should also consider how VS and solutions projects map to the granularity of projects on your version control schema and any branch/merge policies you have.