LINQ to SQL : Bonne ou mauvaise chose ?

par methodiX Ven 4 Fév - 21:21

LINQ to SQL : Bonne ou mauvaise chose ?

On n'est pas dans un match développeur contre DBA où l'inverse... Je
cherche surtout à mettre en avant les points clefs de l'intérêt ou non
de LINQ des 2 côté de la barrière.
Les plus de LINQ

Les développeurs n'écriront plus de SELECT * et passerons
systématiquement la liste des champs au moteur, de ce point de vue
certains cas d'optimisation côté SQL seront mieux traités
Les noms d'objets sont totalement qualifié : « schéma.objet »
sans que le développeur ai à s'en préoccupé, là aussi c'est un plus
important pour des questions de performance et de sécurité.
Le format de la requête SQL est géré par LINQ, ainsi que
contenu, double avantage permettant de limiter très fortement les
risques d'injection SQL et de permettre de meilleures réutilisations de
plans basé sur le texte de la requête.
Certaines requêtes (de type « renvoie-moi les 20
enregistrements après le 2500 par rapport à tel critères ») sont très
simplifiées vue du développeur et ne nécessitent pas de connaissances
approfondies du code SQL.
C'est une bonne couche d'abstraction de code SQL, cela améliore
pas mal l'interopérabilité entre les moteur de base de données. A
condition toute fois que les éditeurs d'autres moteurs jouent le jeu.

Les moins de LINQ

Le code SQL/LINQ est géré côté application ce qui oblige en cas de
patch du schéma à revoir le code de l'application, idem en cas
d'optimisation un peu poussé. Forcera-t-on le DBA à mettre le nez dans
le code de l'application ?
Là où certaines requêtes sont plus simples, d'autres au
contraire deviennent vite très complexes, c'est le cas par exemple des
jointures externe. Cela force le développeur à résonner à l'aide de sous
requête et le code devient alors plus lourd qu'en SQL.
Rajouter une couche d'abstraction revient à alourdir l'ensemble
de l'accès aux données et à ralentir encore un peu plus l'ensemble. Pas
de miracle ici, interopérabilité signifie généralement sacrifier un peu
les performances.
La gestion des transactions reste pour le moment un peu floue,
est ce que le traitement est fait à 100% au niveau du moteur SQL ou un
mix .Net / SQL. Rajouter une couche d'abstraction fait un peu perdre de
vue cette notion et son contrôle.

Mini-Conclusion non définitive
LINQ est globalement une bonne chose pour des requêtes simples. Les
développeurs peu expérimentés en base de données devraient aussi y
trouver leur bonheur. Je suis très content par exemple que les requêtes
sur des fenêtres de données soient gérés toutes seules, mais la méthode
utilisée par LINQ est un bon compromis facilité / maintenance, en aucun
cas la méthode la plus rapide dans toutes situations.
Par contre ce qu'il ne faudrait pas oublier c'est que le DBA risque
de perdre le contrôle des requête ce qui risque de provoquer des
dégradations de performance, et risque d'obliger à patcher de plus en
plus l'application.
Pour des tâches complexes de traitement de données personnellement je
resterais côté serveur avec mes procédures stockées. L'un n'empêche de
toute façon pas l'autre. Dernier point, j'aime beaucoup l'aspect intérop
de la chose.
Bon débat…

[source]

par methodiX Ven 4 Fév - 21:27

Un autre lien pour comprendre Linq to SQL :

[Vous devez être inscrit et connecté pour voir ce lien]

par methodiX Sam 5 Fév - 3:22

un autre lien:

[Vous devez être inscrit et connecté pour voir ce lien]

par Contenu sponsorisé

LINQ to SQL : Bonne ou mauvaise chose ?

LINQ to SQL : Bonne ou mauvaise chose ?

Re: LINQ to SQL : Bonne ou mauvaise chose ?

Re: LINQ to SQL : Bonne ou mauvaise chose ?

Re: LINQ to SQL : Bonne ou mauvaise chose ?