V. Architecture 3-tiers et mise en place du
modèle MVC
Une application Web possède souvent une architecture
3-tiers :
· la couche dao s'occupe de l'accès aux
données, le plus souvent des données persistantes au sein d'un
SGBD.
· La couche métier implémente les
algorithmes " métier " de l'application. Cette couche est
indépendante de toute forme d'interface avec l'utilisateur. Ainsi elle
doit être utilisable aussi bien avec une interface console, une interface
web, une interface de client riche. Elle doit ainsi pouvoir être
testée en-dehors de l'interface web et notamment avec une interface
console. C'est généralement la couche la plus stable de
l'architecture. Elle ne change pas si on change l'interface utilisateur ou la
façon d'accéder aux données nécessaires au
fonctionnement de l'application.
· La couche interface utilisateur qui est l'interface
(graphique souvent) qui permet à l'utilisateur de piloter l'application
et d'en recevoir des informations.
Les couches métier et dao sont normalement
utilisées via des interfaces Java. Ainsi la couche métier ne
connaît de la couche dao que son ou ses interfaces et ne connaît
pas les classes les implémentant. C'est ce qui assure
l'indépendance des couches entre-elles : changer l'implémentation
de la couche dao n'a aucune incidence sur la couche métier tant qu'on ne
touche pas à la définition de l'interface de la couche dao. Il en
est de même entre les couches interface utilisateur et métier.
L'architecture MVC prend place dans la couche interface
utilisateur lorsque celle-ci est une interface web. La figure 9, illustre
l'architecture 3-tiers et la mise en place du MVC.
Figure 9: Architecture 3-tiers et mise en place du
MVC.
Le traitement d'une demande d'un client se déroule selon
les étapes suivantes :
1/ Le client fait une demande au contrôleur. Celui-ci voit
passer toutes les demandes des clients. C'est la porte d'entrée de
l'application. C'est le C de MVC.
2/ Le contrôleur C traite cette demande. Pour ce faire,
il peut avoir besoin de l'aide de la couche métier. Une fois la demande
du client traitée, celle-ci peut appeler diverses réponses. Un
exemple classique est :
· une page d'erreurs si la demande n'a pu être
traitée correctement.
· une page de confirmation sinon
3/ Le contrôleur choisit la réponse (une vue)
à envoyer au client. Choisir la réponse à envoyer au
client nécessite plusieurs étapes:
· choisir l'objet qui va générer la
réponse. C'est ce qu'on appelle la vue V, le V de MVC. Ce choix
dépend en général du résultat de l'exécution
de l'action demandée par l'utilisateur.
· lui fournir les données dont il a besoin
pour générer cette réponse. En effet, celle-ci contient le
plus souvent des informations calculées par le contrôleur. Ces
informations forment ce qu'on appelle le modèle M de la vue, le M de
MVC. L'étape 3 consiste donc en le choix d'une vue V et en la
construction du modèle M nécessaire à celle-ci.
4/ Le contrôleur C demande à la vue choisie de
s'afficher. Il s'agit le plus souvent de faire exécuter une
méthode particulière de la vue V chargée de
générer la réponse au client.
5/ Le générateur de vue V utilise le modèle
M préparé par le contrôleur C pour initialiser les parties
dynamiques de la réponse qu'il doit envoyer au client.
6/ La réponse est envoyée au client. La forme
exacte de celle-ci dépend du générateur de vue. Ce peut
être un flux HTML, PDF, Excel... Dans notre application, et pour plus de
simplicité, la couche métier est intégrée au
générateur de vue.
| 
