La manipulation des données

By Antoine P. ************************************ La manipulation des données : Procédures stockées, ORM a quel moment doivent-ils être utilisés ? Afin de vous présenter brièvement les raisons pour lesquelles cette question peut être amenée à se poser, je vais me présenter brièvement. En arrivant dans ma toute première mission, j’ai tout d’abord découvert la stack du projet, puis en arrivant vers la couche d’accès aux données il y a avait un ORM (Entity Framework) utilisé avec LINQ (Language-Integrated Query) et toute une autre partie qui ne faisait ni plus ni moins que des appels à des procédures stockées en base de données. Il est important de noter que l’ORM n’intervient pas du tout sur la même couche que les procédures stockées. Il est donc important de ne pas les comparer. En milieux scolaires, dans mon cas du moins, nous avions eu la notion et la pratique d’un ORM, de même pour les procédures stockées. Mais nous n’avions jamais eu l’occasion de les appliquer dans un domaine concret et par conséquent de voir a quel moment il est important d’utiliser l’un par rapport ou l’autre ou alors les deux. Cependant quels sont leurs avantages et leurs inconvénients ? Peuvent-ils se compléter ou sont-ils incompatibles ? Quel est le choix le plus pertinent selon les situations ? Nous allons tenter d’apporter certains éléments de réponses, en abordant l’ORM et les procédures stockées sans rentrer dans le détail ADO.NET ou EF.

1- L’ORM

Image source : https://www.developpez.net/forums/attachments/p474863d1/a/a/a

A – Avantages

Il n’y a plus besoin de se soucier de la base de données utilisée derrière
La quantité de code est réduite
Une fois les connaissances de l’ORM maitrisées, les mises en place de règles de développement objet sont parfois plus facile à maitriser pour l’ensemble des développeurs.
Les équipes de développement (hors BDD) n’ont pas besoin de se soucier du fonctionnement de la base de données

B – Inconvénients

La gestion des requêtes plus complexe n’est pas toujours évidente (par rapport au traditionnel SQL)
Le débuggage des requêtes n’est pas toujours simple, selon les outils mis à disposition et il n’est pas toujours possible de placer des logs car les requêtes sont interprétées. On se retrouve dans certains cas à récupérer la requête générée en SQL afin de la reproduire coté base pour débugger.
Une fois que l’on maitrise le SQL, quel que soit le projet ces connaissances ne sont pas perdues. Or, concernant l’ORM, dès que l’on change de langage, l’ORM change dans la grande majorité des cas. Cela entraine donc une nécessité pour les équipes de tout re apprendre.
Beaucoup d’automatisation, on fait du one to one sur la DB, on ramène beaucoup d’objets inutiles par facilité et c’est peu précis. Il est possible de spécifier des DAO plus précisément, mais cela rajoute beaucoup de code et prends un temps de développement supplémentaire

2- Les procédures stockées

A – Avantages

Toute la compléxité des requêtes est géré dans la procédure stocké Cela permet de dissocier la partie client de cette complexité, qui se contentera seulement de faire les appels à ces procédures.

Toutefois, posséder du métier coté base de données est loin d’être optimal dans certains cas.

Il y a beaucoup plus de documentation SQL notamment grâce à son ancienneté
Certaines requêtes complexes sont beaucoup plus faciles à réaliser en SQL
Il est possible de créer des requêtes et de ne se soucier qu’à l’exécution de ces dernières sans pour autant avoir connaissance du schéma relationnel ou autre.

B – Inconvénients

Etant stockées coté base de données, les procédures stockées augmentent la charge du serveur.
Forte dépendance au SGBD
On a vite tendance à gérer une grande partie du métier de ce côté et la dépendance à la DB est donc beaucoup plus importante.

3- Privilégier la spécification du DAO

Il est indéniable que la simplicité de l’ORM est très utile dans certains cas. Cependant le mapping d’objets à l’identique de la base de données peut s’avérer être néfaste car beaucoup d’objets inutiles sont ramenés. Les performances peuvent également être impactées. Une bonne solution serait de créer des DAO spécifiques à chaque besoin même si cela n’est pas toujours possible selon l’ancienneté du projet, la complexité ou encore les compétences de l’équipe de développement.

4- Utiliser l’ORM pour le CRUD simple et les procédures stockées pour externaliser la complexité

Finalement il n’y a pas de solution miracle et le choix se fait en fonction de la performance attendue, de la complexité du projet et des compétences des équipes. Le legacy est aussi un facteur important. Une approche intéressante c’est d’utiliser l’ORM pour toute la partie CRUD qui est assez simple. Dans ce cas on tire avantage des performances et de la simplicité de l’ORM sans se soucier de toute la partie complexe. On dédiera alors toute la complexité aux procédures stockées. Cela aurait pour avantage de laisser des traitements complexes (qui pourrait répondre à différents contextes, etc.…) coté BDD et de ne pas la ramener sous forme DAO et donc de perdre au niveau performance et simplicité.