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 séparant les contrôles Blazor, etc. sont très lourds. Nous sommes bien loin des bonnes pratiques Agile de simplicité des développements.

Il est vrai qu’en théorie, si nous avions juste voulu créer une application pour réaliser le peu de besoin métier exposé dans PROFI, il aurait été possible de créer simplement un exécutable avec tout le code en dur et une API contenant le métier et les accès à la base de données. Une autre possibilité aurait été de réaliser la totalité en Blazor Server, ce dernier s’exécutant sur le serveur nous donnant la possibilité d’accéder directement à la base de données. Si l’application ne devait vraiment faire qu’afficher des personnes et des contrats, les méthodes Agile recommandent de produire 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 : PROFI s’inspire d’une vraie application, de façon à montrer des problématiques réalistes de performance lorsqu’on...