Quand vous essayez d’utiliser des programmes ILE procurant tous les avantages d’ILE, il est difficile de continuer avec les anciens modèles. Et c’est là que vous commencez à maudire ILE parce que vous ne savez pas où placer l’accès aux fichiers, ni où diviser votre code, ni comment renseigner sur
Il est temps d’apprendre de nouveaux modèles

l’erreur. Vous devez absolument imaginer de nouveaux modèles pour vos programmes !
Beaucoup d’experts recommandent une stratégie MVC (Model-View-Controller) pour écrire de nouvelles applications. Dans cette architecture, le « modèle » est un module qui contient toute la logique de gestion. Le « vue » est un modèle qui assure l’interface avec l’utilisateur. Le « contrôleur » est le code qui contrôle le flux de votre programme et transmet les données de gestion à l’interface utilisateur, et réciproquement. Beaucoup d’experts suggèrent aussi un module « base de données », lui aussi séparé du modèle. Vous pourrez ainsi écrire des mécanismes différents pour le stockage des données, si nécessaire.
Le principe de base de ce modèle est qu’aucun des composant ne doit connaître ni même supposer la manière dont les autres composants fonctionnent. Le modèle n’a pas à savoir s’il reçoit son entrée d’un terminal à écran passif, d’une page Web, ou d’un programme batch. Et peu lui importe de savoir si sa sortie ira dans un sous-fichier, sera imprimée sur un rapport, ou servira à créer un graphique. De la même manière, la vue ne s’intéresse pas à la manière dont le modèle fonctionne. Qu’importe comment la taxe est calculée ou comment l’entreprise détermine le prix d’un article. Sa mission est de présenter les données à l’utilisateur, un point c’est tout.
Quant au contrôleur, il lui suffit de savoir comment appeler des procédures modèle et vue dans le bon ordre. Il doit connaître un peu de chacune, mais il peut ignorer les particularités. Par exemple, il devrait savoir que votre vue est une page Web, et par conséquent qu’il accepte une entrée et renvoie une sortie et qu’il doit appeler le modèle et visualiser les routines dans le bon ordre. Mais il n’a pas à savoir si la sortie est en HTML ou en XML, ou que vous devez écrire un enregistrement de sous-fichier dans une boucle : c’est du ressort de la vue. De même, il n’a pas à savoir comment le modèle s’est procuré l’information qu’il renvoie : c’est l’affaire du modèle.
Le module base de données n’est généralement utilisé que directement à partir du modèle et les autres composants l’ignorent complètement. Un module base de données séparé serait utile si vous vouliez passer du RLA (record-level access) de RPG en SQL, par exemple, ou peutêtre stocker les données dans XML au lieu d’une base de données. Ou bien, si vous vouliez stocker vos données sur un autre système, vous pourriez changer le module base de données et laisser tout le reste fonctionner normalement sans qu’aucun des autres composants n’ait connaissance du changement.
Différente et plus souple, cette approche vous oblige à développer de nouveaux modèles à la place de ceux que vous avez toujours utilisés. Quand vous maîtriserez bien ces modèles, vous pourrez écrire de nouvelles applications, aussi facilement que les anciennes.
Téléchargez cette ressource

Guide de Cyber-résilience pour Microsoft 365
La violation de votre tenant M365 va au-delà d’un simple incident de cybersécurité. Elle peut entraîner une interruption opérationnelle généralisée, des perturbations commerciales et une exposition de vos données sensibles. Découvrez les méthodes et technologies pour évaluer, comparer et renforcer votre posture de sécurité Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les banques passent à l’action avec l’IA générative et le cloud
- DSI en assurance : gardien du temple ou moteur de la transformation ?
- Ransomware : persistance des cyberattaques à l’échelle mondiale
- Cybersécurité : l’IA générative rebat les cartes du cybercrime
- Le World Cyber Ranking, 1er classement mondial de la cybersécurité des entreprises
