Una gran adición del Framework 2.0 en cuanto a codificación, fueron las clases parciales. Surgieron como una excelente solución sobretodo para los generadores automáticos de código, pues anteriormente cuando no habían clases parciales y uno trabajaba sobre una clase generada por alguna herramienta, el trabajo ejecutado se perdía cada vez que se regeneraba dicha clase.

Gracias a las clases parciales entonces, uno podía generar un archivo "paralelo" que hacía referencia a la misma clase, pero que no se veía afectado en las regeneraciones automatizadas. Todo esto con la gran ventaja de que a pesar de que estuvieran en archivos distintos, la clase aparecían al resto del mundo como una sola (intellisense, compilación, etc).

Otro uso interesante, es la posibilidad de dividir grandes clases en unidades con funcionalidades comunes, para obtener una mayor administrabilidad de las mismas y para permitir que varios desarrolladores estuviesen trabajando sobre una misma clase (en las versiones parciales en archivos distintos)  al mismo tiempo.

Ya para el Framework 3.5 se incluyeron los métodos parciales que van un paso más allá con este concepto.

La idea es que en una clase parcial se incluye la firma del método (tiene que ser privado y con tipo de retorno void) y en otra clase se "implementa". Lo pongo entre comillas, porque implementar me lleva a pensar en una interfaz, donde obligatoriamente se tiene que implementar los métodos establecidos por ella. Con los métodos parciales no existe esa OBLIGACION. El desarrollador decide si quiere "implementar" o no los métodos parciales que define la clase parcial.

Para saber qué metodos parciales incluye una clase, basta con recurrir al intellisense y escribir "partial" y dar espacio; inmediatamente saldrán todos los métodos parciales disponibles.

Esto resulta muy últil también en el proceso de personalización de código generado automáticamente, tal como pasa con la generación del modelo de datos que ofrece el Entity Framework. Las clases generadas por este framework, agregan métodos parciales para que se puedan controlar los cambios a los atributos en las clases generadas. Entonces si el desarrollador quiere establecer un control granular sobre estos cambios, implementa los métodos parciales en sus clases parciales externas.

Qué ventajas ofrece esta metodología comparada con una de Interfaces?

Si se fuera a autogenerar código con una herramienta como el Entity Framework, basado en una interfaz o en una clase base (con métodos virtuales o abstractos), obviamente la implementación de los métodos dictados por la interfaz quedarían en el código autogenerado o se haría muy complicado el proceso de escoger el archivo donde se quiere generar estos métodos y si se quieren generar o no pues tal vez ya han sido modificados.

Además hay otra ventaja y es que cuando los métodos parciales no son implementados, entonces ni sus firmas ni sus llamados se incluyen en la compilación del código, lo que hace el proceso de compilación y el resultado de la misma, mucho más liviano que cuando se usan interfaces, o cuando se crean métodos virtuales o abstractos.

En conclusión, vemos como muchas de las innovaciones del Framework .NET tienden a hacer más práctica la programación, sin perder el formalismo que lo ha caracterizado a través de su historia. La aparición de métodos parciales son una buena noticia y entender muy bien su uso nos permitirá desarrollar excelentes piezas de  código con muy poco esfuerzo.

Pueden encontrar información de referencia aquí.