A l'image des classes partielles, les méthodes partielles permettent d'éclater le code d'une méthode à travers plusieurs fichiers. Mais à quoi cela peut-il bien servir ?
Grosso-modo, à faire cohabiter la génération de code (il y en a partout aujourd'hui: ASP.NET 2.0, LINQ, ADO.NET dans Visual Studio 2005, WF, WPF) avec les êtres humains que nous sommes. Oui, les développeurs sont des êtres humains. ;-)
Il y a environ un an, je pestais contre le TableAdapter pour un certain nombre de raisons. L'une d'entre elles était:
"Le TableAdapter n'implémente aucune interface (il hérite juste de ComponentModel, ce qui ne nous avance pas à grand chose)"
Il était par exemple impossible de savoir quand un TableAdapter était instancié: son constructeur étant défini dans la classe partielle, il était impossible de le redéfinir. De toute évidence, Microsoft n'a pas utilisé les TableAdapters pour ses développements. Par contre ils utilisent LINQ, et pour LINQ ils ont créé les méthodes partielles. Explications.
Dans LINQ, le code généré contient une floppée de méthodes partielles, qui vous permettent d'écrire votre code de customisation pour à peu près tout. Par exemple, si j'ai une table MaTable dans ma base, LINQ définit une classe MaTable. Supposons que je veuille valider les lignes ajoutées à MaTable, il me suffit d'écrire:
public partial class MaTable
{
partial void OnValidate()
{
if(Colonne<3) throw new Exception("Pas bien!");
}
}
Notez le mot clé partial devant la définition de OnValidate().
Cela est possible car LINQ génère la classe MaTable en tant que classe partielle, et y place une méthode partielle OnValidate() qu'il appelle lors d'un ajout/mise à jour. Le code de notre méthode partielle OnValidate() est donc automatiquement appelé.
Avec Visual Studio 2008, nous pouvons donc dire adieu aux TableAdapters ainsi qu'aux soucis liés.
Comments