一个解决方案中有多少个项目太多了? [英] How many projects in a solution is too many?

问题描述

一个解决方案中有多少个项目是可以接受的?对于那些项目编号较大的应用程序，您是否将其他编译的 dll 放在某个公共文件夹中以便能够运行该应用程序?

How many projects in a single solution is acceptable? And for those apps that have large project numbers do you put the other compiled dlls in some common folder to be able to run the app?

推荐答案

由于在 Visual Studio 中，项目编译为程序集，因此您应该问自己的问题是我应该拥有多少个程序集?"

Since in Visual Studio a project compiles to an assembly, the question you should ask yourself is "how many assemblies should I have?"

如果没有理由单独使用程序集，则没有理由将它们拆分为多个项目.如果您有多个程序集来强制分层，这就是命名空间的用途.

If there's no reason for the assemblies to be used separately, there should be no reason to have them split in several projects. If you have several assemblies to enforce layering, that's what namespaces are for.

在理想的设置中，您应该为应用程序中的每个不同主机创建一个项目(= 一个程序集)，并为非主机特定逻辑创建一个项目.

In an ideal setup, you should have one project (= one assembly) for each different host in your application, and one for your non-host specific logic.

尽管如此，您可能希望根据不同部分的工作人员来拆分项目，但实际上，请尝试限制解决方案中的项目数量(在我写这篇文章时，我正在努力解决 70+ 项目解决方案，所以我是从我个人经验的深渊谈起).

YMMV though, you may want to split projects according to who is working on the different parts, but really, try to limit the number of projects in your solution (as I'm writing this, I'm struggling with a 70+ projects solution, so I'm talking from the abysses of my personal experience).

关于应用程序逻辑/物理分层的有趣讨论可以在 Patrick Smacchia 的博客上找到(例如 http://codebetter.com/blogs/patricksmacchia/archive/2008/02/10/layering-the-level-metric-and-the-discourse-of-method.aspx )

A interesting discussion on logical/physical layering of applications can be found on Patrick Smacchia's blog (for instance http://codebetter.com/blogs/patricksmacchia/archive/2008/02/10/layering-the-level-metric-and-the-discourse-of-method.aspx )

这篇关于一个解决方案中有多少个项目太多了?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！