您何时决定将大型项目拆分为较小的项目？
何时/何地决定将大型Visual Studio项目拆分为较小的多个项目？ 如果它可以重复使用？ 什么时候项目太大了？ （但是有多大太大了？）
当你拆分项目时，你呢，
-
按数据库表分组
-
按类似function分组
-
其他..
许多项目的优点：
- 更容易隔离代码进行unit testing。 我喜欢隔离依赖于大型外部服务器的代码，例如与SMTP服务器通信的代码获得自己的程序集，与数据库通信的代码获取自己的程序集，与Web服务器通信的代码，代码是纯粹的业务逻辑，如validation。
少数项目的优点：
- Visual Studio变得更快
- 一些开发人员只是没有实现分担责任的愿景，并且会开始在各地开设课程，因此您最终会遇到额外项目的痛苦以及将所有项目放入一个项目的好处。
- 每个项目都有一个配置，当您决定项目配置时，通常您必须在任何地方制作相同的chagne，例如设置或更改强名称密钥
许多解决方案的优点
- 您稍后达到了最高项目级别。
- 每次点击f5时，只会编译当前解决方案中的内容
- 如果预计项目在应用程序的生命周期中不会发生变化，为什么要反复重新编译？ 称之为完成并将其移至自己的解决方案。
许多解决方案的缺点
- 由您决定解决方案之间的依赖关系并首先手动编译依赖关系。 这导致了复杂的构建脚本。
项目应该具有凝聚力 。 逻辑应该是相关的，并实现类似的目标
这个答案取决于您支持的产品的大小。 通常，我们按照域和逻辑组织项目。 我们将进一步划分，你划分得越多，你必须做的就越多，或者你会遇到可怕的递归依赖问题。
当我选择拆分项目时，它会变得太大或两个区域变得太相似。
当复杂性上升时，我不会按表拆分，我通常会拆分function。
可重用性是减少代码行的另一个绝佳时机，同时也是一个新项目。 但是要小心你引入了多少“实用程序”库，因为它们确实会影响可读性/可理解性。
我不认为沙子中有一条线说，如果你达到3k SLOC，你就会有太多。 这一切都是语境。
当项目的总体目标保持不变，但是类的数量变得越来越大时，我倾向于创建文件夹和命名空间以更好地在项目中分组function。 彼此耦合的类往往位于相同的文件夹/命名空间中，因此，如果我需要了解给定的类，则相关的类在解决方案资源管理器中就在附近。 如果我意识到某个特定function在目的上有很大差异或者现有项目之间存在共同依赖关系，我通常只会创建新项目。
我通常会得到一些相对较小的Framework项目，这些项目定义了其他项目之间松散耦合的接口，以及针对不同类型的具体function的更大项目。 这至少是UI的一个项目和逻辑和数据的一个项目（如果数据层本身变得非常大，通常会分成两个项目。）
我将代码移动到一个新项目，如果它具有其他项目可用的一般function（理论上）。 如果项目很大，因为它代表了一个复杂的问题，那么命名空间提供了一种很好的方法来为代码带来顺序。 在这里，您可以为每个SQL表等引入（子）命名空间等。
我总是有几个项目（因此是一个解决方案），而不是一个包含我所有源代码的项目。
在某些情况下，它是不可避免的，因为您正在使用和开源库并希望能够调试它。 但更务实的是，我通常让我的应用程序通过插件提供function。 这允许我在运行时更改行为或提供用户可选择的行为。 在非插件的情况下，它允许您更新程序的一部分而不更新所有内容。 在某些情况下，您可以显然提供主要function，并且只在需要时下载模块/组件。
另一个原因是您可以创建较小的测试应用程序来执行程序集，而不是构建一个非常大的解决方案，并且可能要求用户在到达您要测试的部分之前执行多个（和不相关的）GUI操作。 这不仅仅是一个测试问题 – 也许你的组织中不太精明的用户只希望被提供与他们有关的位。