Quels sont les avantages de LINQ à SQL?
je viens tout juste de commencer à utiliser LINQ pour SQL sur un projet de taille moyenne, et j'aimerais mieux comprendre les avantages qu'offre L2S.
un inconvénient que je vois est qu'il ajoute une autre couche de code, et ma compréhension est qu'il a des performances plus lentes que l'utilisation de procédures stockées et ADO.Net. Il semble également que le débogage pourrait être un défi, en particulier pour les requêtes plus complexes, et que celles-ci pourraient finir par être déplacées vers un proc stocké de toute façon.
j'ai toujours voulu un moyen d'écrire des requêtes dans un meilleur environnement de développement, les requêtes L2S sont-elles la solution que je cherchais? Ou avons-nous créé une autre couche au-dessus de SQL, et avons-nous deux fois plus de soucis?
5 réponses
avantages L2S offre:
- Pas de la magie des cordes, comme vous l'avez dans les requêtes SQL
- Intellisense
- Compiler vérifier lors de modifications de base de données
- développement plus Rapide
- Unité du régime de travail (contexte)
- objets de domaine générés automatiquement qui sont de petits projets utilisables
- chargement Paresseux.
- apprendre à écrire des requêtes linq / lambdas est un must learn for. NET promoteurs.
en ce qui concerne la performance:
- il est très probable que la performance ne sera pas un problème dans la plupart des solutions. Pré-optimiser est un anti-modèle. Si vous voyez plus tard que certaines parties de l'application sont à ralentir, vous pouvez analyser ces parties, et dans certains cas même échanger quelques requêtes linq avec des procédures stockées ou ADO.NET.
- Dans de nombreux cas, la fonctionnalité de chargement différé peut accélérer les performances, ou au moins simplifier le code beaucoup.
en ce qui concerne le débugage:
- à mon avis déboguer Linq2Sql est beaucoup plus facile que les procédures stockées et ADO.NET. I recommend that you take a look at Linq2Sql Debug Visualizer, qui vous permet de voir la requête, et même déclencher une exécution pour voir le résultat lors du débogage.
- vous pouvez également configurer le contexte pour écrire toutes les requêtes sql dans la fenêtre de la console, plus d'informations ici
concernant un autre calque:
- Linq2Sql peut être vu comme une autre couche, mais c'est purement couche d'accès aux données. Les procédures stockées sont également une autre couche de code, et j'ai vu de nombreux cas où une partie de la logique opérationnelle a été mise en œuvre dans les procédures stockées. Cela est bien pire à mon avis parce que vous êtes alors la scission de la couche d'affaires en deux endroits, et il sera plus difficile pour les développeurs d'obtenir un clair vue du domaine des affaires.
quelques réflexions rapides.
LINQ en général
- interrogation des collections en mémoire et des mémoires de données hors processus avec la même syntaxe et les mêmes opérateurs
- déclaratif style fonctionne très bien pour les requêtes - il est plus facile de lire et d'écrire dans de très nombreux cas
- Neat language integration permet à de nouveaux fournisseurs (en cours et hors processus) d'être écrits et de profiter de la même expression de requête syntaxe
LINQ to SQL (or other database LINQ)
- écrire des requêtes là où vous en avez besoin plutôt que comme procs stocké rend le développement beaucoup plus rapide: il y a beaucoup moins d'étapes impliquées juste pour obtenir les données que vous voulez
- beaucoup moins de chaînes (procs stockés, noms de paramètres ou tout simplement SQL) impliqués où les fautes de frappe peuvent être irritants; l'autre côté de cette pièce est que vous obtenez Intellisense pour votre requête
- Sauf si vous êtes aller travailler avec les données" brutes " de ADO.NET de toute façon, tu auras un modèle d'objet quelque part. Pourquoi ne pas laisser LINQ S'en charger pour vous? J'aime assez être en mesure de faire une requête et récupérer les objets, prêt à l'emploi.
- Je m'attends à ce que la performance soit parfaite - et là où elle ne l'est pas, vous pouvez l'accorder vous-même ou vous rabattre sur SQL. L'utilisation d'un ORM ne supprime certainement pas le besoin de créer les bons index, etc, et vous devriez habituellement vérifier le SQL généré pour les non-trivial requêtes.
ce n'est en aucun cas une panacée, mais je préfère de loin faire des requêtes SQL directement ou utiliser des procs stockés.
juste comme une mise à jour, voici quelques liens sur le futur de LINQ à SQL:
Quel Est L'avenir de Linq à SQL
Microsoft a-t-il confirmé sa position sur LINQ à SQL end-of-life?
LINQ to SQL est-il mort ou vivant?
comme un commentaire dans le dernier lien indique, LINQ à SQL ne va pas disparaître, tout simplement pas "améliorée" au moins par Microsoft. Prendre ces commentaires et les messages que vous, juste être prudent dans vos plans de développement.
je dois dire qu'ils sont ce que vous avez été recherchez. Il faut du temps pour s'y habituer, mais une fois que vous l'avez fait, vous ne pouvez pas penser à revenir en arrière (du moins pour moi). En ce qui concerne linq par rapport aux procédures stockées, vous pouvez avoir de mauvaises performances sur l'un ou l'autre si vous le construisez mal. J'ai déménagé à linq pour sql quelques procédures stockées d'un client qui ont été mal codées, de sorte que le temps est passé de 20secs (totalement inacceptable pour une application web) à < 1 sec. Et beaucoup moins de code que la procédure stockée solution.
mise à Jour 1: vous obtenez aussi beaucoup de flexibilité, car vous pouvez limiter les colonnes de ce que vous obtenez et il ne récupérera en fait que cela. Sur la solution de type procédure stockée, vous devez définir une procédure pour chaque jeu de colonnes que vous obtenez, même si les requêtes sous-jacentes sont les mêmes.
nous sommes passés récemment à LINQ2Entity pour L'environnement Entity Framework. Avant, nous avions des Sqladapteurs basiques. Puisque la base de données avec laquelle nous travaillons est plutôt petite, Je ne peux pas commenter la performance de LINQ.
je dois admettre cependant, écrire des requêtes est devenu beaucoup plus facile, et l'ajout d'Entities, ne permet forte Dactylographie.