许多项目的优点：

少数项目的优点：

许多解决方案的优点

许多解决方案的缺点

项目应该具有凝聚力 。 逻辑应该是相关的，并实现类似的目标

这个答案取决于您支持的产品的大小。 通常，我们按照域和逻辑组织项目。 我们将进一步划分，你划分得越多，你必须做的就越多，或者你会遇到可怕的递归依赖问题。

当我选择拆分项目时，它会变得太大或两个区域变得太相似。

当复杂性上升时，我不会按表拆分，我通常会拆分function。

可重用性是减少代码行的另一个绝佳时机，同时也是一个新项目。 但是要小心你引入了多少“实用程序”库，因为它们确实会影响可读性/可理解性。

我不认为沙子中有一条线说，如果你达到3k SLOC，你就会有太多。 这一切都是语境。

当项目的总体目标保持不变，但是类的数量变得越来越大时，我倾向于创建文件夹和命名空间以更好地在项目中分组function。 彼此耦合的类往往位于相同的文件夹/命名空间中，因此，如果我需要了解给定的类，则相关的类在解决方案资源管理器中就在附近。 如果我意识到某个特定function在目的上有很大差异或者现有项目之间存在共同依赖关系，我通常只会创建新项目。

我通常会得到一些相对较小的Framework项目，这些项目定义了其他项目之间松散耦合的接口，以及针对不同类型的具体function的更大项目。 这至少是UI的一个项目和逻辑和数据的一个项目（如果数据层本身变得非常大，通常会分成两个项目。）

我将代码移动到一个新项目，如果它具有其他项目可用的一般function（理论上）。 如果项目很大，因为它代表了一个复杂的问题，那么命名空间提供了一种很好的方法来为代码带来顺序。 在这里，您可以为每个SQL表等引入（子）命名空间等。

我总是有几个项目（因此是一个解决方案），而不是一个包含我所有源代码的项目。

在某些情况下，它是不可避免的，因为您正在使用和开源库并希望能够调试它。 但更务实的是，我通常让我的应用程序通过插件提供function。 这允许我在运行时更改行为或提供用户可选择的行为。 在非插件的情况下，它允许您更新程序的一部分而不更新所有内容。 在某些情况下，您可以显然提供主要function，并且只在需要时下载模块/组件。

另一个原因是您可以创建较小的测试应用程序来执行程序集，而不是构建一个非常大的解决方案，并且可能要求用户在到达您要测试的部分之前执行多个（和不相关的）GUI操作。 这不仅仅是一个测试问题 – 也许你的组织中不太精明的用户只希望被提供与他们有关的位。

上述就是C#学习教程：您何时决定将大型项目拆分为较小的项目？分享的全部内容，如果对大家有所用处且需要了解更多关于C#学习教程，希望大家多多关注—计算机技术网(www.ctvol.com)!