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

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

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

服务引用是另一个例子，其中部分类用于将生成的代码与用户创建的代码分开。

您可以在更新服务引用时“扩展”服务类，而不必覆盖它们。

我看到的另一个用法是，

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

我有各种文件的名字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..
}

除了其他答案之外……

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

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

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

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

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

Partial classes are primarily introduced to help Code generators, so we (users) don't end up loosing all our work / changes to the generated classes like ASP.NET's .designer.cs class each time we regenerate, almost all new tools that generate code LINQ, EntityFrameworks, ASP.NET use partial classes for generated code, so we can safely add or alter logic of these generated codes taking advantage of Partial classes and methods, but be very carefully before you add stuff to the generated code using Partial classes its easier if we break the build but worst if we introduce runtime errors. For more details check this https://web.archive.org/web/20211020111732/https://www.4guysfromrolla.com/articles/071509-1.aspx