Y a-t-il de toute façon ce code peut être refacturé? La seule différence est l'ordre par partie.
Iont, je voudrais utiliser une expression déléguée / lambda afin que le code soit réutilisable, mais je ne sais pas comment ajouter et supprimer des opérateurs de requête Orderby et OrderbyDescendant P >
var linq = new NorthwindDataContext(); var query1 = linq.Customers .Where(c => c.ContactName.StartsWith("a")) .SelectMany(cus=>cus.Orders) .OrderBy(ord => ord.OrderDate) .Select(ord => ord.CustomerID); var query2 = linq.Customers .Where(c => c.ContactName.StartsWith("a")) .SelectMany(cus => cus.Orders) .OrderByDescending(ord => ord.OrderDate) .Select(ord => ord.CustomerID);
5 Réponses :
avec des chiffres, etc., vous pouvez normalement nier simplement la "variable de commande". p>
avec DateTime code>, je ne suis pas si sûr. Vous pouvez essayer d'utiliser un
tispan code>. P>
Vous pouvez diviser votre requête en bits et utiliser la logique de contrôle de contrôle. LINQ to SQL construira par magie la requête correcte comme si vous aviez la saisie d'une seule ligne! La raison pour laquelle cela fonctionne est que la requête n'est pas envoyée à la base de données tant que vous ne demandez que les données, mais sont stockées comme une expression.
var linq = new NorthwindDataContext(); var query = linq.Customers .Where(c => c.ContactName.StartsWith("a")) .SelectMany(cus=>cus.Orders); IOrderedQueryable<Order> query2; if (useAscending) { query2 = query.OrderBy(ord => ord.OrderDate); } else { query2 = query.OrderByDescending(ord => ord.OrderDate); } var query3 = query2.Select(ord => ord.CustomerID);
Errorrr !!!!!!!!! Votre commande doit arriver avant de sélectionner, sinon vous traitez avec un type différent :)
Merci Mark. Cela compte-t-il si la commande par les opérateurs de requête est placée après la sélection ()?
@Leppie: Ouais, désolé je n'ai pas remarqué ça!
Eh bien, si vous avez une condition où vous décidez si la commande par est ascendante ou décroissante, vous pouvez utiliser ce
Voir, vous avez fait la même erreur que la réponse ci-dessous (elle est maintenant corrigée).
@Leppie: Non seulement il est corrigé, mais c'est au-dessus de maintenant, pas ci-dessous. Donc, votre commentaire est inexact et probablement plus déroutant que utile! Pourquoi ne pas simplement répéter votre commentaire plutôt que d'essayer d'utiliser une référence? En d'autres termes, écrivez simplement ceci: «Votre commande doit arriver avant de sélectionner, sinon vous traitez avec un type différent». ;-)
Là, corrigé-le. Cependant, je pense que je préfère que Jon réponde aussi bien ;-)
@Mark Byers: Il n'est pas inexact, car vous avez un ordre de tri différent. Le mien est par défaut (le plus récent en premier), votre commentaire est donc inexact! :)
@Leppie: Oh, j'ai oublié que l'ordre de tri est configurable. J'ai juste toujours trié par des votes ... Ok, tu gagnes :-p
Vous pouvez créer votre propre méthode d'extension réutilisable qui fera ceci: et similaire pour alors code>: p>
Un peu hors sujet, mais ce qui sera ci-dessus traduire correctement à Linq2SQL? IOW est-il assez intelligent pour voir une méthode «non prise en charge» et l'exécuter avant de créer un arbre de syntaxe et de générer le SQL? Je me demandais juste, jamais essayé. :)
@Leppie: Il suffit de faire appel à les méthodes requérantes existantes - c'est ce qui construit l'arbre d'expression. Notez que cette ne fonctionnera pas i> sur iEnumerable
Droit. Je n'ai pas vraiment plongé cela auparavant. Il exécute donc la requête 'totale' pour recevoir un «syntaxe» pour construire SQL. A du sens, merci :)
return from T in bk.anbarsabts where T.kalaname == str orderby T.date descending select new { T.date, T.kalaname, T.model, T.tedad };