您何时决定将大型项目拆分为较小的项目？

Question

您何时/何地决定将大型Visual Studio项目拆分为较小的多个项目？如果它可以重复使用？什么时候项目太大了？ （但有多大太大了？）

当您拆分项目时，是吗，

• 按数据库表分组

• 按类似功能分组

• 其它..

Answer 1

许多项目的优点：

• 更容易隔离代码以进行单元测试。我喜欢隔离依赖于大型外部服务器的代码，例如与SMTP服务器通信的代码获得自己的程序集，与数据库通信的代码获取自己的程序集，与Web服务器通信的代码，代码是纯粹的业务逻辑，如验证。

少数项目的优点：

• Visual studio变得更快
• 有些开发人员无法实现您的愿景 关于分担责任 并将开始上课 无处不在，所以你最终得到了 额外项目的痛苦和 把一切都放进去的好处 一个项目。
• 每个项目都有一个配置，当您对项目配置做出决定时，通常您必须在任何地方制作相同的chagne，例如设置或更改强名称密钥

许多解决方案的优点

• 您稍后达到最高项目级别。
• 每次点击f5
时，只会编译当前解决方案中的内容
• 如果预计项目在应用程序的生命周期中不会发生变化，为什么要反复重新编译？称之为完成并将其移至自己的解决方案。

许多解决方案的缺点

• 由您决定解决方案之间的依赖关系并首先手动编译依赖关系。这导致了复杂的构建脚本。

Answer 2

项目应为cohesive。逻辑应该是相关的，并实现类似的目标

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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