Sommaire

Explication de la lourdeur de l’application

Peut-être le lecteur se sera-t-il fait la remarque que, pour une application de simple démonstration, le découpage en nombreux projets, l’architecture du client à base de bus de message, le chargement dynamique des composants, etc. était très lourd. Nous sommes bien loin des bonnes pratiques Agile de simplicité des développements.

Il est tout à fait vrai qu’en théorie, si nous avions juste voulu créer une application pour réaliser les besoins métier exposés dans PROFI, il aurait été possible de créer simplement un exécutable avec tout le code en dur et un service web contenant le métier et les accès à la base de données, voire même ne pas utiliser de base de données du tout. Si l’application ne devait vraiment faire qu’afficher des personnes et des contrats, les méthodes Agile recommandent de faire le code le plus simple possible et clairement, le code présent constituerait alors une sur-architecture énorme.

Mais il y a une bonne raison derrière cette apparente surpondération du code de l’application : comme cela a été expliqué au début du présent chapitre, PROFI est dérivée d’une vraie application industrielle, de façon à montrer des problématiques réalistes de performance. Il n’était donc pas question ...