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

Rapport Forrester sur les solutions de sécurité des charges de travail cloud (CWS)
Dans cette évaluation, basée sur 21 critères, Forrester Consulting étudie, analyse et note les fournisseurs de solutions de sécurité des charges de travail cloud (CWS). Ce rapport détaille le positionnement de chacun de ces fournisseurs pour aider les professionnels de la sécurité et de la gestion des risques (S&R) à adopter les solutions adaptées à leurs besoins.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
