[ Retour Accueil ]
Durée de réalisation estimée : 12H00
ce module s'adresse aux développeurs qui connaissent la programmation des classes de base avec le langage C# (module FRM-CS ou niveau équivalent).
Ce module se compose de 3 parties :
[ Commander ]
Après avoir vu comment manipuler les classes fournies par le Framework .NET 2.0, voici le moment venu d'apprendre à en fabriquer, afin de tirer pleinement parti de la POO au niveau de la logique applicative.
S'il fallait résumer l'intérêt de cette technique de programmation en un mot, il faudrait très certainement choisir celui de "réutilisation". Il s'agit en effet d'implémenter un ensemble de fonctionnalités réutilisables par une ou plusieurs applications clientes. Du point de vue de ces dernières, les fonctionnalités se présentent sous la forme d’un composant dont la vocation est de fournir des classes prêtes à l’emploi, exactement comme celles du Framework. Bien sûr, ce mécanisme peut être tout aussi bien exploité de manière interne au sein d'un même projet.
En prenant l’exemple d’une application monolithique, la moindre modification nécessite une recompilation complète suivie d’un redéploiement. À l'inverse, si une mise à jour doit être effectuée dans une application organisée en composants, elle peut avoir lieu au sein du seul composant concerné. La mise à jour se résume ensuite à remplacer l'ancienne version de ce composant par la nouvelle, sans affecter les applications clientes.
De plus, avec une bonne conception, ce type de programmation vise également à s’affranchir des aspects techniques, en se rapprochant au maximum de la logique de l’application. A tire d’exemple, il s’agit de raisonner avec des objets dits "métiers" tels qu’un "client", un "produit" ou une "commande" dans le cadre d’une application commerciale, sans avoir à se préoccuper des opérations internes nécessaires au fonctionnement des ces objets. Cette deuxième idée, aussi importante que la "réutilisabilité" porte le "d'abstraction".
Dans ce chapitre, nous allons apprendre à utiliser les modules de classe, qui constituent le fondement de toute programmation orientée objet, quel que soit le langage utilisé. Une fois les concepts associés à ce type de programmation bien maîtrisés, nous apprendrons au chapitre suivant comment externaliser un ensemble de modules de classe sous la forme d’un composant réutilisable (c'est-à-dire un assembly de type .dll) par d'autres applications.
Pour illustrer les concepts abordés dans ce chapitre, nous nous placerons principalement dans le contexte d'une agence de voyage qui souhaite matérialiser la gestion de ses offres avec des objets Voyage et Croisiere.
Forts des connaissances acquises au chapitre précédent concernant les modules de classe, nous allons pouvoir créer nos premiers composants exécutables !
En fait, seuls les projets de petite taille peuvent rester monolithiques. Lorsqu’un projet commence à devenir quelque peu complexe, il est généralement préférable de le structurer de façon modulaire basée sur la conception de composants spécifiques dits composants "métiers" ou/et sur l’intégration de composants existants prêts à l’emploi.
Cette approche n’est pas nouvelle, mais elle est tend à se généraliser dans l’industrie du développement de logiciels, qu’elle que soit la plate-forme adoptée. Avant de démarrer un nouveau projet, la plupart des entreprises font aujourd’hui appel à des spécialistes qualifiés d’architectes, chargés de cerner et de décrire le besoin en s’appuyant la plupart du temps sur le système de notations UML. Il s’agit donc d’un domaine de compétence à part entière qui vient s’inscrire en amont de la phase de développement. Si vous souhaitez faire connaissance avec cette branche d’activité en plein essor, vous pourrez néanmoins trouver des informations sur le site :
http://www.microsoft.com/france/msdn/architects/default.mspx
Bien entendu, la conception de composants n’est pas réservée aux seuls architectes et nous allons voir comment les réaliser en .NET.
Bien qu’ils commencent tous par un module de classe, il existe différents types de composants que nous allons découvrir au fil des exemples proposés dans ce chapitre.
En fait, nous constaterons que la conception d'un composant de code ainsi que celle d'un contrôle utilisateur (module UserControl) est restée assez proche de celle des composants COM. Toutefois, les adeptes observeront rapidement les nuances qui vont dans le sens de la simplification.
Du fait qu'un composant de code repose sur un module de classe tel que nous avons appris à les créer au chapitre précédent, nous commencerons par reprendre le scénario de notre agence de voyages, en séparant les classes de la partie cliente, dans deux projets distincts qui seront regroupés au sein d'une solution.
Nous apprendrons ensuite à créer un contrôle utilisateur .NET, dont le principe reste dans la lignée des contrôles OCX. Autorisant l'intégration rapide de nouvelles fonctionnalités sous forme de contrôles personnalisés, tous les développeurs Visual Basic savent qu'ils ont grandement contribué au succès de ce langage. Un contrôle utilisateur vient enrichir les contrôles disponibles dans la Boîte à outils de Visual Studio et se développe dans un module de classe héritant de la classe System.Windows.Forms.UserControl.
Nous verrons, avec deux exemples différents, qu'un contrôle utilisateur peut être obtenu soit en combinant plusieurs contrôles existants, dits "contrôles constitutifs", soit par héritage d'un contrôle de base. La conception d’un composant en partant de zéro demande un peu plus d’efforts, mais reste néanmoins possible.
Nous parlerons également d'interopérabilité, de façon à voir comment utiliser un composant COM à partir d'un assembly .NET et inversement.
