C#新增的特性中引起争议的有许多，分部方法(Partial Method)算是个。分部方法通常被定义在一个分部类中，在常规的类文档中也可实现。假如分部方法没有被实现，编译器就不会、对他们进行编译。
分部方法有着严格的限制。他们必须是私有的，不能返回值，不能有输出参数。因为任何针对没有被实现的分部方法的调用都会简单地被忽略，所以说这些限制是很有必要的。反过又意味着，分部方法不能作为一个明确分配的变量。Visual Basic也有分部方法，尽管VB无需对变量的明确分配，他也有同样的限制。
有那么多的限制，有人可能会问，“他们有什么长处?”。这个问题问得好，基本上，分部方法仅被代码生成器在处理轻量级事件的时候使用。就像 Alexander Jung所解释的 ：
分部方法通常(也可能是唯一相关的)的应用场景就是在代码生成的时候用于处理轻量级事件。假设您解析一个数据库或一个XML文档，然后生成了数据类，结果您会发现有数十个类、几百个属性连同一大堆泛型和模板文档等。分部方法另外一个经常被用到的地方是验证，或让属性的setter去更新另一个属性。所以假如您要使用产生的代码，或在运行时有几百个事件和数千个方法调用的话( 其实大多数情况下只用到了其中的一点点)，就让分部方法来吧。分部方法在声明和使用时要比事件容易得多，假如没有用到他们，他们就会消失。
性能的提升并不是没有代价的。从分部方法必须是私有的限制中，Alexander发现了他们的不足之处：
缺点：假如您喜欢元数据驱动的应用，并且已被ASP.NET的数据绑定所困扰时(因为没有其他的方法能够附上元数据)……那么，就准备着在将来丢失信息吧。假如您需要为属性的setter增加一些事件(基于跟踪和调试的需要)，假如您需要某个动态的行为(比如附上某个通用规则引擎)等等，那么就让我们祈祷代码分析器的研发人员能够预知这个场景(或已做好了准备)吧。您有了一个清楚的层的分离，那么实体就应该对UI一无所知吗?是的，将代码直接放到数据类中会破坏层的关系，但是您能够手动地用分部方法实现真正的事件啊。
另外一些人对于C#中的分部方法也是忧虑重重，大部分是关于代码设计器的使用的。Stefan Wenig写道：
首先，我不是很热衷于设计器。我忧虑的是设计器也许很快就会将我们送上过去基于COM研发时的老路，数百个设计器和向导产生了那么多没人想去看的ATL和MCF代码。在我们陷于设计器、创建的无用文档和复杂的构建过程时，使用Ruby的家伙们在笑，因为他们用几行代码就能够解决(联想一下上世纪90年代COM/C 和Java的比较)。难道对于基于代码的研发人员生产率不是C#所首要考虑的(看看VB的设计器驱动的RAD路线图)?我们不应该再沉浸于基于设计器的，企业类库思想的，乐于使用软件工厂代码设计器的幻想中了。团结起来，抵制他们!
Ayende Rahien也没有嘴软：
让我们一起埋葬这些代码设计器吧，竖起分部方法的辉煌墓碑!
