Tous les conseils sur quand Je trouve la syntaxe Linq plus facile et plus puissante, mais je ne suis pas sûr de savoir s'il y a des performances ou d'autres problèmes qui rendent une sélection de données de données préférable.
(J'utilise une API tiers qui fournit un jeu de données qui a été pré-peuplé à partir de la base de données. Je dois filtrer cela plus loin dans la mémoire.)
3 Réponses :
hmm, comparez-vous des ensembles de données avec LINQ à SQL ? Si vous êtes, alors je dirais seulement des jeux de données de fossé et d'aller avec L2S. LINQ à SQL introduit des frais généraux de débogage car il peut être gênant d'obtenir le SQL généré par dynamisme (alors que dans les jeux de données, vous fournissez le SQL en premier lieu), mais dans presque toutes les autres situations, c'est beaucoup plus élégant . Le Chargement différé fonctionnalité est particulièrement utile.
Si vous ne travaillez pas avec une base de données, alors je préférerais toujours Linq (spécifiquement appelé LINQ vers des objets dans ce scénario) sur des jeux de données. La syntaxe est tout simplement beaucoup plus facile et car il n'y a pas de chaînes magiques (c'est-à-dire des déclarations SQL), il est plus facile de tester et vous obtenez des avertissements de la compilation pour les gouttes de frappe, etc. DataTable.Sélectionnez suppose que vous avez déjà renseigné le jeu de données avec des données. Cela peut conduire à de mauvaises conceptions où vous chargez plus de données que nécessaire, juste pour filtrer dans le client. Obtenez SQL Server pour effectuer votre interrogation pour vous et travaillez sur les résultatsset. L2S ne lira que dans la base de données uniquement lorsque vous itérez la collection, il est donc beaucoup plus facile de formuler vos requêtes
Merci pour votre réponse. J'aurais dû préciser que je n'ai pas d'interaction avec la base de données. Je vais mettre à jour la question.
Sans même mentionner Linq, je n'utiliserais pas de datatable.select n'importe où sauf si je n'avais absolument pas à devoir, car dans la plupart des cas, cela signifie que dans le client quelque chose qui devrait probablement être effectué dans la base de données. < / p>
Absolument - bien que ce soit un cas «ait absolument à». Travailler avec une API tiers.
Basé sur une expérience personnelle, j'essaie d'éviter le jeu de données.Sélectionnez. Je trouve que c'est lent et a des bugs étranges.
Un (confirmé et documenté par Microsoft) Bug que j'ai rencontré était que DataTable.Sélectionnez N'a toujours pas toujours évalué et conditions correctement lorsqu'il existe des parenthèses dans la déclaration.
Par exemple, (COL1> 1) et (COL <10) ne peut pas échouer de bonnes réponses, Alors que le col1> 1 et le col <10 fonctionneront correctement.
Ce bogue ne s'affiche pas sur chaque ordinateur. Dans mon cas, le chèque que j'utilisais correctement sur ma plate-forme de développement et chaque ordinateur client sauf un. Après avoir découvert ce bogue, j'ai commencé à passer à l'utilisation de Linq pour sélectionner et remarqua une augmentation significative de la vitesse des opérations.
Note latérale: Sans entrer dans de longues explications, ma société n'utilise pas une base de données pour stocker des données. Tout de nos opérations avec des datables impliquent dans des tables de mémoire chargées à partir de fichiers plats. Donc, je ne parle pas de Linq 2 SQL, mais LINQ to DataSet.