Concevoir de vraies applications client-server

L’ERP que j’ai écrit et maintenu pendant de nombreuses années est une suite d’applications client-server. Ses différents logiciels clients sont développés en .NET :

• Un client « lourd » sous la forme d’un applicatif WinForms.
• Un site web Blazor Server Interactive.
• Une application MAUI de prise d’inventaire.
• Une application MAUI hybride permettant de répondre à des besoins métiers plus spécifiques.
• …

Toutes ces applications s'appuient sur un même serveur de base de données, MS SQL Server.

Compréhension des gains de performance

L’expérience concrète m’a démontré que chaque connexion au serveur SQL a un coût. Malgré l’optimisation qu’apporte .NET via le pool de connexions, chaque connexion consomme du temps. Un temps infime, certes. Mais si ces connexions sont répétées, cela impacte de façon concrète les temps de réponse du logiciel perçue par l’utilisateur.

C’est ici que s’installe une véritable « religion » avec ses dogmes et pratiques qui s’appliquent à la lettre.

• Aucune connexion SQL dans une itération.
• Regroupement de diverses requêtes SQL dans un seul script, envoyé en une fois via une connexion unique.
• L'abandon (ou la minimisation) de l'utilisation de ces petites fonctions utilitaires, certes bien commodes, qui vont chercher une seule donnée dans la base de données.
• …

On comprend ici que cette structuration du code est particulière, et va même à contre-courant des pratiques actuelles de développement.

Chaque requête SQL doit être optimisée, « cousue main », pour aller chercher les derniers millièmes de seconde qu’il est possible d’économiser. Dans ce contexte, où chaque requête SQL est soigneusement optimisée, un ORM n'est généralement pas l'outil le plus adapté.

S’ajoutent à cela les bonnes pratiques d’une programmation connectée à SQL Server :

• Aucun SELECT * FROM.
• Usage du SqlBulkCopy pour charger rapidement des données sur le serveur SQL.
• L’ajout des index pertinents (parfois des index sur les colonnes calculées persistantes).
• L’utilisation de SQL CLR plutôt que T-SQL pour les algorithmes plus complexes.
• …

Un équilibrage de l’effort entre client et serveur

SQL Server peut prendre en charge une partie des algorithmes « métier ». Cela décharge le client de cette part du travail. Le serveur SQL dispose des données sous la main. Il est donc parfois le mieux placé pour effectuer entièrement un processus long et simplement renvoyer, en aval, une valeur attendue.

Les triggers bien conçus (et non récursifs) sont nos amis, car ils sont le meilleur endroit pour exécuter du code qui doit toujours s’exécuter lorsque telle ou telle donnée change. C’est magnifiquement le cas pour mettre à jour les compteurs de quantités en stock en fonction des mouvements d’entrée et de sortie de marchandise.

Intégrité des données

Une base de données est un outil formidable pour assurer l’intégrité des données. Mais il est nécessaire de bien concevoir, à la base, le schéma de la base de données afin que les relations s’accordent parfaitement avec la réalité du terrain que ces données animent.

À cet endroit, il est opportun de traduire en contraintes (au sens SQL du terme) toute une série de validations de données :

• Clés non vides
• Données uniques
• Numéros de TVA
• VCS
• …

Tout ceci garantit finalement que, quel que soit le logiciel client, et peu importe quiconque en soit l’auteur, les données seront toujours celles que le système, dans sa globalité, attend.

Linux

SQL Server a longtemps été exclusivement disponible sous Windows. Il tourne de la même manière sur un serveur Linux. Cela permet de diminuer certains coûts de licence tout en offrant à l’utilisateur final une expérience absolument identique.

Mes dernières installations ont toutes été effectuées sous Ubuntu.

Dans une architecture client-server, la base de données n’est pas un simple espace de stockage auquel les applications viennent puiser des informations. Elle constitue une véritable composante du logiciel, avec laquelle chaque échange doit être pensé et optimisé. Bien exploitée, elle participe aux performances, prend en charge une partie de l’intelligence métier et garantit l’intégrité des données, indépendamment des applications qui les utilisent.