除了其他答案之外……

我发现它们可以作为重构神类的垫脚石。如果一个类有多个职责(特别是如果它是一个非常大的代码文件)，那么我发现为每个职责添加1x个部分类作为组织和重构代码的第一步是有益的。

这非常有帮助，因为它可以帮助使代码更具可读性，而不会实际影响执行行为。它还可以帮助确定何时易于重构某个职责，或者何时与其他方面紧密纠缠在一起。

然而，需要明确的是，这仍然是糟糕的代码，在开发结束时，您仍然希望每个类有一个职责(而不是每个分部类)。这只是一块垫脚石:)

大多数人认为partial只应该用于生成了代码文件的类或接口。我不同意，原因如下。

举个例子，让我们看看c#系统。数学课…这是类。我不会尝试把70多个方法都塞进同一个代码文件中。维持它将是一场噩梦。

将每个数学方法放入单独的部分类文件中，并将所有代码文件放入项目中的math文件夹中，将显著地使组织更加干净。

同样的道理也适用于许多其他具有大量不同功能的类。例如，管理PrivateProfile API的类可以通过在单个项目文件夹中拆分为一组干净的部分类文件而受益。

就我个人而言，我还将大多数人所说的“助手”或“实用工具”类划分为每个方法或方法功能组的单独部分文件。例如，在一个项目中，字符串助手类几乎有50个方法。即使使用区域，这也将是一个冗长而笨拙的代码文件。为每个方法使用单独的部分类文件维护要容易得多。

我只会小心使用部分类，并在整个项目中保持所有代码文件布局一致。例如，将任何类公共枚举和类私有成员放入文件夹中的Common.cs或类似名称的文件中，而不是将它们分散到文件中，除非它们只特定于包含它们的部分文件。

请记住，当您将一个类拆分为单独的文件时，您也失去了使用文本编辑器拆分栏的能力，该功能可以让您同时查看当前文件的两个不同部分。

如果您有一个足够大的类，而不适合进行有效的重构，那么将它分离到多个文件中有助于保持内容的组织性。

例如，如果您有一个包含论坛和产品系统的站点数据库，并且您不想创建两个不同的提供者类(与代理类不是一回事，只是为了清楚起见)，您可以在不同的文件中创建单个分部类，例如

——核心逻辑

cs -专门与论坛相关的方法

产品的方法

这是另一种让事情井井有条的方法。

另外，正如其他人所说，这是向生成的类添加方法而不会在下次重新生成类时破坏所添加的方法的唯一方法。这对于模板生成的(T4)代码、orm等非常方便。

部分类的最大用途是使代码生成器/设计人员的工作更轻松。部分类允许生成器简单地发出它们需要发出的代码，而不需要处理用户对文件的编辑。用户同样可以通过创建第二个分部类来自由地用新成员注释类。这为关注点分离提供了一个非常清晰的框架。

更好的方法是看看设计器在部分类之前是如何工作的。WinForms设计器会吐出区域内的所有代码，并给出不修改代码的强烈注释。它必须插入各种启发式方法来找到生成的代码，以便稍后进行处理。现在它可以简单地打开designer.cs文件，并有高度的信心它只包含与设计器相关的代码。

每当我有一个类，其中包含一个具有重要大小/复杂性的嵌套类时，我将该类标记为partial，并将嵌套类放在一个单独的文件中。我使用规则命名包含嵌套类的文件:[class name]。[嵌套类名].cs。

下面的MSDN博客解释了如何使用带有嵌套类的部分类来实现可维护性:http://blogs.msdn.com/b/marcelolr/archive/2009/04/13/using-partial-classes-with-nested-classes-for-maintainability.aspx

作为预编译器指令的替代方案。

如果您使用预编译器指令(即# If DEBUG)，那么您最终会看到一些看起来粗糙的代码与实际的Release代码混合在一起。

你可以创建一个单独的分部类来包含这些代码，或者将整个分部类包装在一个指令中，或者省略该代码文件，使其不被发送给编译器(实际上是做同样的事情)。