2008-12-03 10 views
1

Je souhaite planifier une couche d'accès aux données et j'ai pensé à utiliser Linq. J'ai lu que linq a ses problèmes avec les performances et que vous pouvez utiliser des procédures stockées avec linq. Dois-je utiliser des procédures stockées avec linq lors de la planification de ma couche d'accès aux données? Est-ce crucial pour la performance? Quand devrais-je les utiliser? Je sais que les procédures stockées sont essentielles pour la sécurité, mais linq utilise des requêtes sécurisées de type sorte que la seule raison pour les procédures stockées est la performance.Utilisation de Linq avec des procédures stockées

Merci,

Omri

+0

"Les procédures stockées sont essentielles pour la sécurité mais linq utilise des requêtes sécurisées de type" - cela n'a pas de sens – TheSoftwareJedi

Répondre

2

D'après ce que j'ai lu, les plans caches du serveur d'exécution de requêtes générées par LinqToSql, de sorte que ces requêtes se produiront à peu près la même manière que serait l'équivalent des procédures stockées. Et si vous utilisez des procédures stockées, vous perdez les avantages que vous obtenez en utilisant LinqToSql, puisque votre logique de requête restera dans la base de données.

Pour plus d'informations sur les performances de LinqToSql, reportez-vous à blog series de Rico Mariani, ainsi qu'à this blog post.

2

Si vous écrivez simplement CRUD, les procédures stockées sont peu susceptibles de vous aider avec les performances. Autant que je sache, le chemin d'exécution d'un proc stocké est à peu près le même que pour une instruction préparée - c'est-à-dire correctement optimisé et mis en cache.

Ils font une grande différence lorsque vous pouvez travailler entièrement dans la base de données, ce qui impliquerait sinon de multiples allers-retours à la base de données (avec le trafic réseau et la latence également). Où avez-vous lu que LINQ a des problèmes de performance? Je connais un problème particulier qui est résolu en précompilant la requête, mais à part cela je pensais que c'était fondamentalement correct ...

+0

J'ai recherché LINQ et les performances dans google et trouvé un tas de liens parlant de ce problème. Comme je l'ai compris LINQ est construit sur ADO.net donc il ne peut pas être plus rapide .. Merci, Omri – Omri

+0

Non, il ne sera pas plus rapide que ADO.NET ordinaire - mais vous n'avez pas posé de questions sur la performance relative à ADO.NET. La principale chose est que LINQ rend votre code plus facile à gérer avec des coûts de performance minimes. –

0

Je recommanderais d'aller avec LINQ ou procédures stockées, mais pas les deux - il n'y a pas de vraie raison de combiner les deux et vous ne gagnerez pas en termes de performance. LINQ serait utile pour les applications Web à petite échelle, les procédures stockées pour une application Web à plus grande échelle ou pour une meilleure évolutivité

Le problème n'est pas seulement la performance comme une application web se développe en termes de nombre d'utilisateurs, pages desservies, etc ... cela devient aussi un problème de maintenance. Si vos requêtes deviennent plus complexes au fil du temps, votre code LINQ pourrait devenir un cauchemar à maintenir. Les procédures stockées restent bien cachées dans la couche de base de données. Et ... peu importe ce que n'importe qui dit, une requête qui s'exécute au niveau de la base de données sera TOUJOURS exécutée plus rapidement.

Questions connexes