Linq2Sql vs procédures stockées

Question

Excuses s'il s'agit d'une question en double, mais existe-t-il une réelle différence entre l'exécution d'une instruction SQL dans Linq2Sql et l'exécution d'une procédure stockée?

Quels sont les avantages? (le cas échéant)

Answer 1

Si vous mettez votre code dans une procédure stockée, vous l'avez découplé de votre application C#. Vous pouvez corriger les erreurs ou étendre ses fonctionnalités sans devoir recompiler et redistribuer votre application. En outre, l'utilisation de la procédure stockée peut être une mesure de sécurité: vous pouvez autoriser vos utilisateurs à exécuter une autorisation sur les processus stockés, mais sans mettre à jour ou insérer de privilèges sur les tables sous-jacentes. Cela peut rendre votre base de données plus sécurisée et plus gérable. D'un point de vue fonctionnel, je dirais que (presque) tout ce que vous pouvez faire dans une procédure stockée peut également être fait avec SQL en cours d'exécution à partir de votre Linq-to-SQL DataContext - mais comme je l'ai mentionné précédemment - dans ce Dans ce cas, vous avez tout votre code SQL dans votre application principale, ce qui peut être une bonne ou une mauvaise chose, selon la manière dont votre application et vos clients travaillent et fonctionnent.

Answer 2

Si la vitesse brute est la préoccupation principale, puis utilisez un DataReader.

Sinon, LINQ to SQL est une alternative solide. Il offre d'énormes avantages en termes de dénomination forte et de sécurité de type. C'est un important stimulant de la productivité. Au fur et à mesure que vous apprenez à écrire de bonnes requêtes LINQ et, en particulier, à apprendre à utiliser des requêtes compilées le cas échéant, vous pouvez obtenir des performances très correctes.

Un programme basé sur LINQ bien conçu ne sera pas non plus une mémoire. Oui, le contexte de données met en cache les résultats de la requête, mais le contexte de données est conçu pour être un objet de très courte durée. Si vous conservez un contexte de données plus long qu'une seule transaction, vous vous trompez. Et si vous en disposez à la fin des transactions, la perte de mémoire a disparu.

LINQ to SQL fournit la meilleure protection possible contre l'injection SQL. Les procédures stockées sont censées être les plus sûres, mais cela ignore le fait que trop de gens mettent du SQL dynamique à l'intérieur des procédures stockées, ce qui annule toute la sécurité des appels paramétrés. LINQ to SQL paramètre tout, et même s'il est très convivial pour les procédures stockées, il n'exécutera pas de procédures stockées utilisant du SQL dynamique.

Answer 3

Un avantage incroyable de LINQ to SQL par rapport aux procédures stockées est que vous pouvez créer votre requête dynamiquement.

De nombreuses requêtes complexes construites dans des procédures stockées sont compliquées principalement parce qu'elles sont construites pour gérer de nombreux cas possibles. Par exemple, une procédure stockée qui implémente un filtre avec de nombreux paramètres possibles, dont certains sont facultatifs, doit être construite pour s'adapter aux diverses permutations et peut devenir très laide. Vous pouvez, bien sûr, construire la même requête dans LINQ to SQL comme une requête de grande taille, mais la beauté de LINQ to SQL est que vous n'en avez pas besoin. En utilisant la logique de contrôle de flux et le chaînage de requêtes, vous pouvez construire une requête plus simple qui utilise uniquement les paramètres actifs dans la recherche, en omettant les vérifications ou la logique alternative nécessaire pour traiter les cas où les paramètres facultatifs ne sont pas fournis . En utilisant Dynamic LINQ et/ou PredicateBuilders, ces requêtes peuvent également être arbitrairement complexes - mais encore plus simples que celles implémentées par la procédure stockée.

Pour accomplir la même chose avec des procédures stockées, vous devez écrire et maintenir de nombreuses procédures stockées différentes, chacune faisant le même travail, mais pas le même. Ensuite, vous devrez avoir la même logique de flux pour choisir entre ces procédures. Cela devient rapidement intenable à mesure que le nombre de paramètres augmente.

Un autre avantage de LINQ, IMO, est qu'il permet au développeur d'écrire les requêtes en utilisant des idiomes plus naturels (dans mon cas, C#). Bien que je puisse écrire du SQL, il est plus naturel pour moi d'écrire du code C#. Je vais mieux et plus vite.