Application de test

1. Une migration historique

Avant de commencer à explorer notre application de test dans ce chapitre, il convient de donner quelques explications sur cette dernière.

Cet ouvrage est la seconde édition et, à cet effet, beaucoup de choses ont changé depuis la première édition sortie en 2011. De ce fait, les chapitres précédents ont été actualisés sur un plan théorique, mais il fallait également actualiser l’application de test afin de refléter les usages modernes.

L’application initiale était une solution composée de deux parties : un webservice ASMX et une application WinForms cliente. Bien que ces technologies existent encore de nos jours, leur utilisation conjointe ne constitue clairement plus un cas d’usage répandu (et si tel est le cas, il doit s’agir davantage de maintenance que de création). Cependant, si ce cas d’usage vous intéresse plus que l’actuel, l’auteur vous recommande de vous procurer la première édition de cet ouvrage, plus adaptée.

Néanmoins, le concept de « client-serveur » perdure toujours, même si aujourd’hui on parlera plutôt de « front-end » et « back-end ». À cet effet, le webservice ASMX a été migré en ASP.NET...

1. Pourquoi cette application ?

Comme cela a déjà été plusieurs fois expliqué auparavant, la philosophie de ce livre n’est pas d’expliquer de manière experte tous les mécanismes internes de .NET ni d’analyser toutes les fines optimisations possibles de la performance, mais de montrer les causes les plus habituelles de dégradation de performance dans des applications .NET. Les causes sont parfois simples, mais trouver le point bloquant précis à partir des symptômes rencontrés est souvent plus complexe. L’idée ici n’est donc pas de faire du tuning, mais de montrer les cas typiques de programmation incorrecte aboutissant à des performances dégradées.

Cela étant posé, il est apparu évident que l’application de démonstration ne pouvait pas être basée sur autre chose qu’un vrai logiciel industriel. Après avoir autant insisté sur le fait que nous devons nous attaquer aux causes réelles, en nous éloignant du point de vue académique, il aurait été malvenu de proposer d’appliquer les méthodes de profilage sur une application de test sans aucun lien avec la réalité.

À cet effet, dans le cadre de la seconde édition, un effort tout particulier a été apporté afin de conserver au maximum tels quels les différents objets et routines métier qui étaient présents dans la première édition. Néanmoins, le changement de technologie a impliqué quelques modifications, où l’auteur a introduit les erreurs de programmation les plus courantes.

2. Utiliser des retours d’expérience

L’utilisation d’une vraie application présente également l’avantage de ne pas avoir à imaginer...

1. Domaine d’utilisation

L’application choisie, ou plutôt la plate-forme choisie pour les démonstrations, car il s’agit d’une plate-forme commune à plusieurs applications, est basée sur .NET 6. La première application utilisant cette plate-forme est une application de gestion tout ce qu’il y a de plus traditionnelle, utilisant des fiches et un système de parcours d’information, le tout agrémenté de modules de reporting, de traitement en masse, etc. La seconde application utilise le même système pour mettre à disposition de l’utilisateur des moteurs de modélisation de calculs budgétaires plus complexes.

2. Architecture

De manière globale, la plate-forme permet de créer des applications composées d’un client Blazor WebAssembly communiquant avec une WebAPI ASP.NET contenant le métier, elle-même en relation avec des bases de données par un mécanisme multibase utilisant directement ADO.NET. Il s’agit ici d’une mutation de l’architecture initiale, qui se verra être transformée au fur et à mesure des avancées pour arriver sur des standards de code modernes.

3. Interface

Le but du livre est de montrer des structures de code et d’architecture de solution peu performantes. Il était donc hors de question d’encombrer...

1. Trouver l’application

L’auteur recommande, pour bien comprendre la suite, de prendre quelques minutes pour bien s’imprégner de l’application de test. Celle-ci, répondant au nom de PROFI, peut être téléchargée sur le site des Éditions ENI ou est disponible directement sur GitHub à l’adresse suivante : https://github.com/hybrid-technologies-solutions/eni-dotnet-perf/tree/main/AvantOptimisation (attention à bien prendre la version dans le dossier AvantOptimisation et non ApresOptimisation).

2. Installation de la base de données

Dans le but de simplifier le travail d’installation de la base de données, l’auteur propose plusieurs approches, parmi lesquelles le lecteur pourra choisir celle qui lui paraît la plus simple à mettre en œuvre. Afin que l’application ne soit pas limitée par les performances du SGBD, SQL Server a été retenu comme base de données. Il est à noter que SQL Server peut librement être lancé sur n’importe quel ordinateur pouvant exécuter Docker.

Pour cela, il faut procéder ainsi :

docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=10mdpAdmin !" -p 
1433 :1433 -d mcr.microsoft.com/mssql/server :2019-latest 

Une fois ces deux étapes exécutées, un conteneur faisant tourner SQL Server aura été monté et sera accessible localement sur le port 1433.

Si le lecteur a déjà installé...