|
Architecture MVC et performance des applications J2EE |
|
|
|
Optimisation -
Performance
|
|
Ecrit par Kamal AOUDA
|
|
20-12-2005 |
|
L’architecture Model
1 permet, certes, d’encapsuler la logique d’affaires dans les Java Beans mais
elle n’évacue pas entièrement le code Java des JSP. Cela pose d’importants
problèmes d’extensibilité et de maintenance dans les applications de grande
taille développées par des équipes très spécialisées. Ces problèmes se résument
comme suit :
• Les équipes de développement tombent rapidement dans le piège de la
décomposition fonctionnelle en ce sens qu’elles créent une nouvelle JSP pour
chaque nouvelle fonctionnalité de l’application. Elles se retrouvent ainsi avec
un nombre exorbitant de JSP et plusieurs lignes de code mal factorisé.
• Les erreurs d’origine humaine se multiplient parce que les membres de l’équipe
de développement touchent accidentellement à des fragments de code qui ne
relèvent pas de leurs attributions (par exemple un designer qui altère
accidentellement le code Java alors qu’il n’est censé travailler que sur la
partie HTML, CSS et Javascript).
La résolution de ce problème exigeait une autre séparation entre la logique de
présentation et la logique de coordination qui permettait aux JSP de diriger les
requêtes vers les Java Beans. C’est ainsi qu’on a ravivé l’ancienne architecture
MVC de SmallTalk que Sun a pour l’occasion baptisé Model 2 en raison de
l’utilisation conjointe des JSP et des servlets dans la même application. En
plus d’ajouter une servlet à l’architecture il a fallu créer des balises XML
comme JSTL pour évacuer entièrement le code Java des JSP. Assurément, cela a
permis aux designers de disposer d’une syntaxe qui leur est beaucoup plus
familière mais a occasionné une augmentation des ressources consommées et du
temps de réponse notamment en raison du parsing des balises XML et de
l’utilisation de langages comme XSL ou XSLT pour les transformations de leur
contenu et la gestion de leur présentation.
Soulignons par ailleurs que les requêtes n’ont plus qu’un seul point d’entrée
vers l’application alors que dans l’architecture Model 1 chaque JSP constitue un
point d’entrée en soi. D’emblée on pourrait présumer que ce design provoque une
congestion des requêtes au niveau du contrôleur et par conséquent un retard dans
leur acheminement vers le Model.
Il est important de souligner que le pattern MVC ne proscrit pas la création de
plusieurs contrôleurs au sein de la même architecture.
Figure 30: Architecture Model 2 [154]
Notes de bas de
page
[154] William
Crawford, Jonathan Kaplan, J2EE Design Patterns, O'Reilly, September 2003,
0-596-00427-3, pages 368
|
|
Dernière mise à jour : ( 20-12-2005 )
|
Accueil 
Optimisation 
