IV. Le site de E-Commerce
1. Architecture 3-tier et mise en place du modèle
MVC Une application web possède souvent une architecture 3-tier
:
1 la couche dao s'occupe de l'accès aux données, le
plus souvent des données persistantes au sein d'un SGBD.
1 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.
1 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
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 :
1 une page d'erreurs si la demande n'a pu être
traitée correctement 1 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:
9
( 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.
2. Configuration de l'application
Chacun des frameworks que nous avons utilisés
nécessite sa propre configuration, en plus de celle requise par le
moteur de servlet. Généralement, cette configuration se fait via
l'utilisation de fichiers XML, bien qu'il soit également possible
d'utiliser d'autres types de fichiers ou de l'effectuer par programmation.
C'est néanmoins la première solution que nous avons retenu.
Globalement, l'architecture d'un projet web Java EE dans eclipse
est la suivante :
On trouve d'abord le repertoire src, qui contient les
packages et les sources java de l'application ainsi que certains fichiers de
configuration, dont ceux d'hibernate (hibernate.cfg.xml) et de spring
(springconfig.xml).
Ensuite, on a le répertoire build, qui
correspond à la version compilée du répertoire
src . En J2EE, quand une page est demandée par l'utilisateur,
le moteur de servlet regarde la version compilée de la servlet qu'il
possède pour cette page et détermine s'il a besoin ou non de
recompiler une version plus récente de
la source correspondant. C'est dans ce répertoire
build que vont toutes ces classes une fois
compilées, ainsi que les copies des fichiers de
configuration présent dans le répertoire src.
Le répertoire WebContent contient quant à lui
toutes les données relatives à une application web classique,
c'est-à-dire que c'est ici que l'on va retrouver nottament les images,
les feuilles de style, les jsp , etc...
Rapport de Projet J2EE Site de E-Commerce
janv. 8
On y trouve également contenu dans le répertoire
WEB-INF , plusieurs éléments importants :
( Un répertoire classes, qui correspond au
répertoire build précédent.
( Un répertoire lib, qui contient tous les jar
nécessaires a l'exécution de l'application. Dans notre cas, entre
les frameworks que nous utilisions et leur dépendances, le nombre
d'archives s'éleve à plus de 40, pour un taille de 10Mo.
( Le fichier de configuration de struts
(struts-config.xml)
( Le fichier de configuration de l'application, nécessaire
pour le fonctionnement du moteur de serlet (web.xml)
En fait, le répertoire WebContent représente,
comme son nom l'indique, le contenu complet nécessaire pour faire
tourner le site web sur un serveur d'application. On se rend plus facilement
compte de cela si l'on exporte notre projet dans un fichier WAR (pour Web
Archive) afin de le mettre en production sur notre serveur Tomcat ou sur un
autre serveur compatible J2EE, tels que Glassfish, le serveur utilisé
par Sun, ou d'autres tels que JBoss, Jonas ou autres. Cette archive ne comporte
dès lors plus que le contenu du répertoire WebContent,
le répertoire classes contenant toutes la partie applicative
écrite en java.
| 
