Accueil Solutions cartographiques & IT Contact

[Avis d’ex­pert] Appli­ca­tions C# : enjeux et avan­tages de la migra­tion sur Linq

Par La rédaction - 5 mai 2020
Temps de lecture : 8min

La gestion des requêtes est primor­dial pour que les éditeurs de logi­ciels puissent mener leurs missions à bien. Pour l’op­ti­mi­ser, GiSmart­ware a fait le choix de la migra­tion sur Linq via un ORM. Pourquoi ? Qu’im­plique ce chan­ge­ment ? Expli­ca­tions de Joffrey Truyen, déve­lop­peur .net chez GiSmart­ware.

 

Quelle archi­tec­ture est en place chez GiSmart­ware pour la gestion des requêtes ?

Actuel­le­ment, notre serveur appli­ca­tif se connecte à 3 systèmes de gestion de bases de données (SGBD) diffé­rentes : SQL, serveur, oracle et post­gresql. Ces 3 types de bases sont main­te­nus afin de pouvoir s’in­té­grer dans le SI de nos clients.

Notre cœur de métier est axé sur des données géogra­phiques. Lors de la créa­tion de la solu­tion NetGeo, le meilleur moyen de trai­ter effi­ca­ce­ment ces données était de les regrou­per en bases via des procé­dures stockées. En effet, aucun ORM ne suppor­tait les données géogra­phiques pour les 3 types de bases de données que nous utili­sons.

Aujourd’­hui, envi­ron 80 % de notre code métier est donc struc­turé en base de données dans les procé­dures stockées. Ce qui implique que ce code doit être écrit pour chaque SGBD avec la syntaxe qui lui est propre. Nous avons donc à main­te­nir 3 versions de chaque procé­dure stockée, ce qui implique que le code métier est écrit 3 fois.

 

Quels défis impose un tel fonc­tion­ne­ment ?

En règle géné­rale, les requêtes de données sont expri­mées comme de simples chaînes, sans véri­fi­ca­tion de type au moment de l’exé­cu­tion, ou de prise en charge Intel­liSense. Il faut donc employer un langage de requête diffé­rent pour chaque SGBD : Oracle (PL / SQL), Sql server (T-SQL), et Post­greSQL (PL / PGSQL).

Ce code métier écrit en 3 fois nous amène à beau­coup de complexité. Cela repré­sente des coûts assez lourds de main­te­nance. En effet, la correc­tion d’un bug implique très souvent une correc­tion à réali­ser pour chaque SGBD. Il arrive égale­ment que des bugs soient dus aux spéci­fi­ci­tés de l’un des SGBD.

 

Quel est votre objec­tif à moyen terme pour amélio­rer la gestion des requêtes ?

Notre objec­tif est de remon­ter à 80 % du code métier dans le serveur en C# afin de faci­li­ter le travail de déve­lop­pe­ment. En effet, actuel­le­ment, comme tout est struc­turé en base de données, les tests unitaires sont très lourds à mettre en place et à main­te­nir car ils dépendent de ces mêmes bases.

Nous savons que nous devrons quoi qu’il en soit garder des procé­dures stockées en base de données, car certaines requêtes sont trop complexes ou coûteuses en perfor­mance. C’est notam­ment le cas du calcul de route télé­com, qui exige de rester très proche de la base de données pour pouvoir formu­ler des requêtes suffi­sam­ment perti­nentes.

 

Comment comp­tez-vous procé­der ?

Nous aime­rions utili­ser un ORM, ou mapping objet-rela­tion­nel. Il s’agit d’un type de frame­work qui permet d’abs­traire la base de données pour travailler avec des classes repré­sen­tant les tables rela­tion­nelles dans notre serveur. On confi­gure donc l’ORM pour défi­nir la rela­tion entre les tables dans les SGBD et avec les objets utili­sés côté appli­ca­tif.

L’ORM va mettre à dispo­si­tion des méthodes pour dialo­guer avec les bases de données. Celles-ci seront ensuite retrans­crites en requêtes SQL par l’ORM selon le type de base de données voulu.

Nous n’au­rions ainsi qu’à travailler avec nos objets appli­ca­tifs et les méthodes four­nies par l’ORM, sans plus se soucier des syntaxes SQL propres à chaque SGBD.

 

Pourquoi ne pas avoir implé­menté d’ORM plus tôt ?

Nous n’avons pas pu effec­tuer une telle migra­tion pour des raisons tech­niques. En effet, à l’époque, il n’y avait pas d’ORM capable de gérer les données géogra­phiques sur nos 3 SGBD cibles.

Cette possi­bi­lité est très récente. Ce n’est que depuis 2017 que l’un des ORM du marché répond à ces besoins en offrant, en plus, une API avec Linq.

 

Quelle méthode avez-vous choi­sie pour dialo­guer avec vos bases de données ?

Chez GiSmart­ware, nous avons choisi d’uti­li­ser un ORM qui offre une API Linq. Linq (Language-Inte­gra­ted Query) est un frame­work repo­sant sur l’in­té­gra­tion de fonc­tions de requête direc­te­ment dans le langage C#, en utili­sant des expres­sion lambda.

Il s’agit d’un stan­dard présent dans Dot Net depuis la version 3.5. Il permet de formu­ler des requêtes en C# sur toute source de données : données en mémoire, fichiers, flux web service, ou encore base de données si l’ORM le permet.

Nous avons choisi un ORM qui intègre ces fonc­tions. Ainsi, si nous venons un jour à chan­ger d’ORM, toutes les requêtes réécrites en Linq demeu­re­ront compa­tibles – à condi­tion qu’une API Linq soit propo­sée.

 

Quels sont les avan­tages d’une migra­tion Linq en C# ?

En ayant recours à Linq, nous n’avons plus qu’une syntaxe à connaître, ce qui faci­lite le travail et nous permet de gagner en effi­ca­cité et réac­ti­vité – notam­ment en matière de gestion des requêtes.

Cela permet égale­ment une montée en compé­tences beau­coup plus rapide pour de nouveaux déve­lop­peurs. Qui plus est, Linq est un stan­dard dans l’uni­vers .net, il y a donc de fortes chances que les nouveaux déve­lop­peurs connaissent cette syntaxe.

En paral­lèle, le fait de remon­ter le code métier côté serveur permet de faci­li­ter le débo­gage. Actuel­le­ment, pour diagnos­tiquer une anoma­lie, iden­ti­fier quelle procé­dure stockée est en erreur, puis lancer les outils de diagnos­tic de la base de données cible, qui ne sont pas toujours évidents à appré­hen­der. Cette procé­dure est bien plus simple côté serveur, où l’on peut passer très faci­le­ment en debug en C#.

Les ORM inté­grant Linq permettent égale­ment de réali­ser beau­coup d’abs­trac­tions pour faci­li­ter ensuite la mise en place de tests unitaires. Il s’agit en effet d’un code supplé­men­taire qui appelle les fonc­tions métier de notre code. Cela nous permet de tester qu’une fonc­tion, même si elle est retou­chée plus tard, affiche toujours le même compor­te­ment et les mêmes résul­tats. Nous pouvons donc opérer des modi­fi­ca­tions tout en étant assez sereins quant à la livrai­son finale.

Pour finir, avec un ORM, il est possible d’effec­tuer des tran­sac­tions sur une action métier globale. Par exemple, si l’on met à jour un droit pour un utili­sa­teur, nous devons solli­ci­ter plusieurs procé­dures stockées diffé­rentes, donc réali­ser plusieurs petites tran­sac­tions. Si tout est remonté dans notre serveur, nous pouvons alors englo­ber l’en­semble des procé­dures dans une seule et même tran­sac­tion. Cela repré­sente un véri­table gain en matière de gestion des requêtes et tran­sac­tions.

Par La rédaction - 5 mai 2020

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

La face cachée du SaaS : où en sont les éditeurs de logiciels français ?
Présentation C.R.E.D.O. - juin 2020

Recommandé pour vous

S'inscrire à la newsletter

Pour ne rien rater de notre actualité...