Nicolas CLERC Consultant associé

TEKIGO est une société de conseil et d’expertise en ingénierie logicielle, spécialisée dans l’accompagnement technologique, essentiellement autour de la plate-forme Microsoft®.NET, des entreprises et des collectivités publiques, de la startup aux grands comptes.

La plupart des développeurs démarrent en WPF de la même façon qu’en Winform Nommage de tous les contrôles Gestion des handlers sur les évènements provenant des contrôles dans le code behind Stockage des références au modèle objet dans le code behind Alimentation directe des contrôles par code

Approche programmatique plutôt que déclarative Couplage fort entre le code d’interaction avec les données et l’interface utilisateur Usage de références de noms et de types Contraintes pour le responsable du design de l’application Difficile à tester, pas de test unitaires sur le code behind Pas d’utilisation du Databinding bidirectionnel, une des fonctions les plus puissantes de WPF

View : La couche graphique de l’application Utilise le « ViewModel » dans son « DataContext » pour le « binding » S’occupe de transformer les données en éléments visuel avec les « Data Templates » Vous savez qu’elle est bien faite si il n’y a quasiment pas de « code behind » à part les animations et la gestion de « layout » View : La couche graphique de l’application Utilise le « ViewModel » dans son « DataContext » pour le « binding » S’occupe de transformer les données en éléments visuel avec les « Data Templates » Vous savez qu’elle est bien faite si il n’y a quasiment pas de « code behind » à part les animations et la gestion de « layout » ViewModel : Expose à la vue les données nécessaires Doit implémenter INotifyPropertyChanged (ou DependencyObject) et ObservableCollection Expose les comportements pour la vue (habituellement, les commandes) Spécifique pour chaque vue mais n’hérite d’aucune classe WPF Ne fait aucune supposition sur comment la couche graphique va binder Facile à tester unitairement ViewModel : Expose à la vue les données nécessaires Doit implémenter INotifyPropertyChanged (ou DependencyObject) et ObservableCollection Expose les comportements pour la vue (habituellement, les commandes) Spécifique pour chaque vue mais n’hérite d’aucune classe WPF Ne fait aucune supposition sur comment la couche graphique va binder Facile à tester unitairement Model/DataModel : Responsable des données métiers Si les données sont trop lourdes, utiliser un pattern spécifique pour ne pas bloquer la couche graphique Peut combiner plusieurs sources de données Model/DataModel : Responsable des données métiers Si les données sont trop lourdes, utiliser un pattern spécifique pour ne pas bloquer la couche graphique Peut combiner plusieurs sources de données Le Pattern Model-View-ViewModel

Première version de notre application

Développement parallélisé des composants avec problématique de licences, déploiement partiel des modules, voire de versions spécifiques de modules : Chargement dynamique des modules Modification de la structure d’affichage du Shell de l’application Communication entre ces modules (sans inter- dépendance)

L'objectif du Composite Application Guidance pour WPF (CompositeWPF) est de fournir un Framework sur lequel viendront se greffer des applications WPF modulaire. Ce socle, destiné à s'interfacer avec le Desktop, préfigure en quelque sorte le bureau WPF de demain Découpage: possibilité d’adopter tout ou partie du framework. Permet d’activer ajouter ou enlever facilement des fonctionnalités Extensibilité : permet d’ajouter, de remplacer des morceaux du Framework facilement Testabilité : l’implémentation de référence permet d’utiliser un pattern de séparation de la couche de présentation et rend donc l’UI testable

Mise en œuvre du Bootstrapper et chargement des modules

« Shell » – Fenêtre principale « Regions » – Zone nommée pour le placement des vues « Views » – UI + logique de présentation Region <ContentControl RegionManager.RegionName= “ZoneB” /> <ContentControl RegionManager.RegionName= “ZoneB” />

Définition de la structure d’affichage du Shell et injection de dépendance

Développement isolé des composants avec problématique de licences, déploiement partiel des modules, voire de versions spécifiques de modules : Chargement dynamique des modules Modification de la structure d’affichage du Shell de mon application Communication entre ces modules (sans inter- dépendance)

« Event Aggregator » Publication/Souscription d’évènements faiblement couplés « DelegateCommand » & « Composite Command » Module B Order Detail Module A Order Event Aggregator Subscribe Publish Event

Agrégation d’évènements

Commandes composites, suppression des dépendances binaires

Développement d’une application métier sous Windows WPF est la technologie d’aujourd’hui WPF >= Effet Whoaaaaaaaa !!! Puissance du Databinding Séparation de l’aspect visuel et de la logique d’interaction Adéquation à de multiples patterns : M-V-VM, Routed Command Développement d’une application composite sous Windows Composite Application Guidance for WPF & Composite Application Library : Best Patterns & Practices et implémentation de référence Chargement dynamique des modules : BootStrapper et injection de dépendance Définition la structure d’affichage du « Shell » : Concept de « régions » Communication inter-modules : Agrégation d’évènements Commandes composites

Blog de Nicolas Clerc Tekigo Blog de Stéphane Goudeau Blog de John Gossman’s Blog de Dan Crevier pattern-series.aspx pattern-series.aspx Blog de David Hill’s Composite WPF and Silverlight

14 – 15 avril 2010, CICG

Classic Sponsoring Partners Premium Sponsoring Partners