Principes de base de MVC

présentation multiples
(GUI et navigateur, par exemple)
pour la vue, et chaque couche peut utiliser
les mêmes règles de gestion et entrée.
Une modification touchant l’un
des éléments MVC d’une application
n’affecte pas forcément les autres. De
plus, comme la modularité inhérente à 
l’architecture MVC se traduit par des
parties plus étroites et plus spécialisées,
la maintenance de l’application en est grandement facilitée.

Les figures 1 et 2 représentent les
architectures héritées et MVC, respectivement.
Dans la première, on voit une
implémentation héritée classique dans
laquelle les utilisateurs interagissent
avec l’application par l’intermédiaire
d’une station de travail à  écran passif.
Dès que l’utilisateur entre des demandes
d’informations, le programme
RPG traite les demandes, ou requêtes,
et affiche les informations sur la station de travail du demandeur. Notons qu’un
seul programme RPG contient toute la
logique nécessaire pour interagir avec la
station de travail, effectuer l’I/O de base
de données, et appliquer les règles de
gestion. Il en résulte beaucoup d’interdépendance
entre les parties de l’application.

La figure 2 montre une application
modulaire dans laquelle les utilisateurs
interagissent avec l’application par l’intermédiaire
d’un navigateur avec un moteur ASP (Active Server Page). Le navigateur
et ASP représentent la vue.
L’ASP invoque un module driver RPG
qui constitue le modèle. Le driver RPG
contient les règles de gestion régissant
le traitement. Le module d’I/O et la base
de données représentent le contrôleur.

Contrairement à  l’ancienne architecture,
l’architecture MVC permet de
modifier ou d’étendre l’application en
échangeant, ou en permutant, des composants.
C’est ainsi que l’on peut changer
la vue (passer d’une interface navigateur
à  une GUI, changer la sortie du
navigateur à  l’imprimante, par
exemple) sans affecter le modèle ou le
contrôleur.