Depuis que LINQ to SQL est essentiellement une couche au-dessus de Ado.net, il nécessite une certaine traduction. Cela signifie-t-il que l'utilisation directe de Ado.net est plus rapide que LINQ? Ou la différence est-elle si petite que ce n'est pas pertinent?
4 Réponses :
Dans l'exécution, il est fractionnellement plus lent. Cependant, Linq à SQL enregistre le temps de développeur qui est le principal avantage, IMHO.
gentillesse,
dan
Techniquement, oui, il y a des frais généraux et LINQ2SQL peut générer quelque moins que le SQL optimal parfois, mais à moins que vous ne travaillez à haute performance ou à haut débit, il est probablement peu probable de le remarquer.
Mes conseils seraient choisis la technologie DA qui convient le mieux à vos besoins. N'oubliez pas que les avantages des choses comme Linq2SQL ou EF sont réduites du temps de développeur consacré à la rédaction de couches de DA répétitives et de réduire le code (donc en théorie peut-être réduit les bugs et moins de maintenance - bien que cela soit discutable). Ensuite, profilez pour la performance plus tard et si vous détectez un cou de bouteille, vous pouvez commencer à optimiser des requêtes spécifiques alors, et si les requêtes très importantes, qui provoquent des cravates de gros bouteilles pouvant être converties en simple simple ado.net
Cela signifie que Ado.net est plus rapide. Il vous donne également des tas de plus de liberté d'optimisation de vos requêtes SQL (bien techniquement, vous pouvez utiliser LINQ vers SQL avec des procédures stockées uniquement, mais que vous manquiez sur tout le point).
Le fait est que si vous avez vraiment vraiment vraiment besoin d'optimiser les meilleures performances, personne ne recommande vraiment d'utiliser un ou / m. Il y a des tas de considérations avec ou / m: S, performance-sage. Mais beaucoup de sites n'ont pas vraiment besoin d'optimiser que beaucoup pour la performance, de la même manière que nous pouvons vous permettre de programmer dans .net plutôt que assemblant, même si c'est le même genre de frais généraux que par rapport au code d'écriture dans une langue de niveau inférieure.
Le point d'utiliser Linq vers SQL ou NHibernate, ou vraiment tout autre ou / m est celui (comme avec l'analogie .NET), cela vous donnera beaucoup de commodité, et cela vous fera économiser beaucoup de Développement de temps et faire refactoriser et d'autres modifications plus tardes une tâche beaucoup plus simple.
Je voudrais juste ajouter un détail mineur: il y a beaucoup de développeurs de DB-Incends là-bas. Certains d'entre eux écrivent toujours SQL et certains d'entre eux écrivent vraiment SQL Crappy. Certains ou / ms (par exemple L2S) font une juste quantité d'optimisation de la requête avant de frapper la DB, de sorte que, bien que la matérialisation de l'objet, etc. puisse avoir un peu de frais généraux, vous pouvez également obtenir d'énormes gains de performance latéraux de la DB si vous avez des devs DB-ignorant sur votre équipe ... JMHO.
Il est vrai que LINQ to SQL est une couche au-dessus de ADO.NET. Mais d'autres options vous permettent de conserver les résultats en mémoire. Si votre intention consiste à agir sur les données immédiatement après la récupération, vous ferez mieux de travailler avec ADO.NET DateReader dans une boucle pour une meilleure performance. Toutefois, si vous devez effectuer un traitement ultérieur sur les données, vous devez conserver une mémoire en informatique à l'aide d'une sorte de variable telle qu'une linq à SQL Entity ou DataTable. Ces deux variables de mémoire sont essentiellement générées de la même manière sous les couvertures. Compte tenu de ce fait, je dirais que la vitesse dont chaque option est disponible en mémoire n'est pas aussi importante que vous envisagez de travailler avec les données.
Voici quelques points de repère ( ORMBattle.net )