> Tech > Il est temps d’apprendre de nouveaux modèles

Il est temps d’apprendre de nouveaux modèles

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

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

Les mégatendances cybersécurité et cyber protection 2024

Les mégatendances cybersécurité et cyber protection 2024

L'évolution du paysage des menaces et les conséquences sur votre infrastructure, vos outils de contrôles de sécurité IT existants. EPP, XDR, EDR, IA, découvrez la synthèse des conseils et recommandations à appliquer dans votre organisation.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010