II. ARCHITECTURE DE
DEPLOIEMENT
La technologie Objet requiert une architecture. C'est cette
architecture qui organise les interactions entre objets. On a l'habitude de
regrouper ces objets en classes, ces classes en domaines, et ces domaines en
couches.
Les couches permettent de présenter l'architecture de
l'application. Les équipes de réalisation s'attribuent alors des
responsabilités sur le développement de chaque couche. Aussi, si
modéliser est indispensable, construire une architecture à couche
est un critère de qualité dans le cadre d'un développement
Objet. Reste à choisir le nombre de couches et à définir
leur contenu.
A. Architecture 3-Tiers
Pour avoir une architecture robuste, modulable et
évolutive, il nous faut utiliser le principe de
« couche ». Nous allons donc séparer au maximum les
différents types de traitement de l'application (Dao, Métier,
Présentation).
Ceci correspond à une architecture 3-Tiers :
Figure 54 : Architecture 3 tiers
B. Architecture MVC
L'architecture Modèle Vue Contrôleur (MVC) est
une méthode de conception pour le développement d'applications
logicielles qui sépare le modèle de données, l'interface
utilisateur et la logique de contrôle. Ce modèle d'architecture
impose la séparation entre les données, les traitements et la
présentation, ce qui donne trois parties fondamentales dans
l'application finale : le modèle, la vue et le
contrôleur :
- Le Modèle : représente le comportement de
l'application : traitements des données, interactions avec la base
de données, etc. Il décrit les données manipulées
par l'application et définit les méthodes d'accès.
- la Vue : correspond à l'interface avec laquelle
l'utilisateur interagit. Les résultats renvoyés par le
modèle sont dénués de toute présentation mais sont
présentés par les vues. Plusieurs vues peuvent afficher les
informations d'un même modèle. Elle peut être conçue
en html, ou tout autre « langage » de présentation.
La vue n'effectue aucun traitement, elle se contente d'afficher les
résultats des traitements effectués par le modèle, et de
permettre à l'utilisateur d'interagir avec elles.
- le Contrôleur : prend en charge la gestion des
événements de synchronisation pour mettre à jour la vue ou
le modèle. Il n'effectue aucun traitement, ne modifie aucune
donnée, il analyse la requête du client et se contente d'appeler
le modèle adéquat et de renvoyer la vue correspondant à la
demande.
En résumé, lorsqu'un client envoie une
requête à l'application, celle-ci est analysée par le
contrôleur, qui demande au modèle approprié d'effectuer les
traitements, puis renvoie la vue adaptée au navigateur, si le
modèle ne l'a pas déjà fait.
Un avantage apporté par ce modèle est la
clarté de l'architecture qu'il impose. Cela simplifie la tâche du
développeur qui tenterait d'effectuer une maintenance ou une
amélioration sur le projet. En effet, la modification des traitements ne
change en rien la vue. Par exemple on peut passer d'une base de données
de type SQL à XML en changeant simplement les traitements d'interaction
avec la base, et les vues ne s'en trouvent pas affectées.
| 
