Le N-tiers (partie 2)
Une architecture N-Tiers parfaite supposerait l'indépendance totale de l'IHM, des traitements et de la base, reliés les uns aux autres par des objets connecteurs.
Maintenant je pense qu'il faut adapter cette manière de concevoir à ce que savent faire Windev et WebDev afin d'utiliser au mieux les fonctionnalités proposées. Il ne faut pas oublier qu'on est sensés développer 10 fois plus vite !
Solution proposée :
1) La base de données :
On va partir du principe que la base aura toujours la même structure bien qu'elle puisse être de type différent. Ce cas peut se rencontrer avec des clients très attachés à leur base, que ce soit Oracle, SQLServeur ou autre. Chacun a de bonnes raisons pour ça.
On va également considérer que cette base pourra accepter les mêmes noms de champs et les mêmes cardinalités qu'un système de fichiers Hyper File.
Avec OleDb ou accès natif on va donc pouvoir gérer tout (ou presque) de la même manière quel que soit le type de base.
On économise ainsi la classe connecteur BASE <--> TRAITEMENT
2) L'interface :
A mon avis très rares sont les applications qui doivent fonctionner avec plusieurs interfaces qui n'ont rien à voir ! On peut éventuellement tomber sur des clients qui exigent des couleurs, des types de champs ou des éléments de décors qui leur sont propres mais je crois que ça doit être intégré à même l'application avec un panneau d'administration dédié à ça. Certes c'est de la complexité à gérer mais ça reste dans la même interface.
Par contre le besoin de faire tourner la même application en WebDev nécessite bien une application à part ... et donc une IHM physiquement différente. Ceci-dit on retrouvera les mêmes informations à renseigner (par exemple une date et un interrupteur pour un état) mais pas les mêmes mécanismes, un site ne fonctionnant pas forcément comme une appli pour Windows en utilisation ... et pas du tout pareil en mécanique interne.
Exemple :
Pour cet exemple je vais partir d'un cas simple, un traitement nécessitant une petite interface de sélection.
Les paramètres saisis seront stockés dans un fichier (ou table) TRAIT_UTIL.
Important : on utilisera la possibilité qu'offrent Windev et WebDev de rattacher les champs aux rubriques (data binding).
Fenêtre :
On trouve deux classes de gestion : Gestion_Base <-- Gestion_Cloture
Classe Gestion_Base :
Un mécanisme de récupération et d'écriture des zones du traitement pour l'utilisateur en cours est implémenté à même cette classe de base.
Les méthodes bDebutSpecif( ) et bTraitementSpecif() permettent d'appeler un traitement spécifique pour la classe dérivée (Gestion_Cloture)
Des traitements standards (comme cette gestion de valeurs par défaut) peuvent être implémentés dans la classe de base avant ou après le traitement spécifique.
Classe Gestion_Cloture :
Seules les méthodes bDebutSpecif( ) et bTraitementSpecif() sont implémentées.
Leur code est tout à fait spécifique à ce traitement ci.
Remarquez bien que le champ Cloture.SAI_ANNEE est directement utilisé.
On aurait pû utiliser la syntaxe d'indirection suivante { sFenetre + ".ZONE" , IndChamp } mais je suis parti du principe suivant :
- Les pages WebDev et les fenêtres WinDev auront le même nom.
- Les noms des champs auront également les mêmes noms.
Cette solution facilite grandement la vie !
Code dans la fenêtre :
NOTE : volontairement je ne suis pas passé par les modèles de fenêtres afin de ne pas superposer des notions de natures différentes. On considère donc que la fenêtre est bien une fenêtre sans modèle.
Code dans le bouton "Traitement" :
Ce qu'on peut constater : il y'a un minimum de code dans l'IHM, juste les appels nécessaires.
Dans la partie 3 je mettrais en oeuvre la même chose en WebDev ... en essayant de me fatiguer le moins possible :-)