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

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

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

我注意到两个用法，我在答案中没有明确找到。

分类项目分组

一些开发人员使用注释来分离类的不同“部分”。例如，一个团队可能使用以下约定:

public class MyClass{  
  //Member variables
  //Constructors
  //Properties
  //Methods
}

对于分部类，我们可以更进一步，将部分分割到单独的文件中。按照惯例，团队可以在每个文件后面加上与之对应的部分。所以在上面我们会有这样的东西:MyClassMembers.cs, MyClassConstructors.cs, MyClassProperties.cs, MyClassMethods.cs。

正如其他答案所暗示的那样，是否值得将班级分开可能取决于在这种情况下班级的规模。如果它很小，那么把所有东西都放在一个大师班可能会更容易。但是，如果这些部分中的任何一部分太大，它的内容可以移动到一个单独的分部类中，以保持主类的整洁。在这种情况下，惯例可能是在节标题后留下类似“See partial class”的注释，例如:

//Methods - See partial class

管理使用语句/命名空间的范围

这种情况可能很少发生，但是来自您想要使用的库的两个函数之间可能会发生名称空间冲突。在单个类中，最多只能为其中一个使用using子句。对于另一种，您需要一个完全限定的名称或别名。对于部分类，由于每个名称空间& using语句列表都不同，因此可以将两组函数分离到两个单独的文件中。

一个很好的用法是将生成的代码与属于同一类的手写代码分离。

例如，由于LINQ to SQL使用部分类，您可以编写自己的某些功能片段的实现(如多对多关系)，并且当您重新生成代码时，这些自定义代码片段不会被覆盖。

WinForms代码也是如此。所有设计器生成的代码都放在一个文件中，您通常不会接触这个文件。手写的代码放到另一个文件中。这样，当您在设计器中更改某些内容时，您所做的更改不会被影响。

分部类的主要用途是生成代码。如果你看看WPF (Windows Presentation Foundation)网络，你用标记(XML)定义你的UI。该标记被编译成部分类。您可以用自己的部分类填充代码。

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

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

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

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

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

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

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

我看到的另一个用法是，

扩展一个关于数据访问逻辑的大型抽象类，

我有各种文件的名字Post.cs,Comment.cs,Pages.cs…

in Post.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of post..
}


in Comment.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of comment..
}

in Pages.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of Pages..
}