Applications Web monolithiques (MVC)

modèle de gestion, la vue ou UI, et un contrôleur qui les relie. Il s’agit bien de séparer la vue du modèle de telle sorte que les changements apportés à la première n’affectent pas le second, et réciproquement. Le contrôleur fournit ce découplage.

« Le modèle ne sait rien de l’UI ; il fournit simplement un ensemble de services ou d’API qui permettent de lire ou de modifier l’état du modèle. Le contrôleur associe ensuite, de manière standardisée, le flux d’informations et les événements entre la vue et le modèle.

« Au niveau de conception, cela signifie que les changements apportés aux contrôles ou aux éléments individuels de l’UI n’affectent pas le modèle. Au niveau architecture, cela signifie que les changements apportés au client n’affectent pas le modèle. »

L’emploi du modèle de conception MVC a pour conséquence que votre code JSP ne contient pas de logique de gestion. Et donc, la maintenance de la JSP peut être confiée à des programmeurs non Java. Qui plus est, ce code peut être maintenu avec divers éditeurs WYSIWYG, comme Dreamweaver, FrontPage ou WebSphere Development Studio Client (WDSc). De plus, les applications MVC sont plus faciles à remanier. Et, peutêtre le plus important de tout, vos composantes de gestion sont testables – sans recourir à la couche de présentation – par des méthodologies de test de facto, comme JUnit (junit. org) et le test automatisé avec Ant.

MVC n’est pas un produit ou une spécification Sun : c’est un modèle de conception, une stratégie standard visant à séparer la présentation de la programmation. Mais n’essayez pas de créer votre propre architecture MVC. Cela a déjà été fait. Il existe une bonne dizaine de frameworks MVC opensource, mais celui qui s’est imposé comme le standard de facto est Jakarta Struts.