> 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

Reporting Microsoft 365 & Exchange

Reporting Microsoft 365 & Exchange

Comment bénéficier d’une vision unifiée de vos messageries, protéger vos données sensibles, vous conformer aisément aux contraintes réglementaires et réduire votre empreinte carbone ? Testez la solution de reporting complet de l’utilisation de Microsoft 365 et Exchange en mode Cloud ou on-premise.

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