Discussion :

[patamuche]

Bonjour,
Voila j'ai une simple liste Annee contenant deux champs : IdAnnee et NomAnnee
Dans une méthode, j'ai crée une méthode QueryAnnee de type IEnumerable<Annee> dans laquelle je fais une requete link pour trier mes années
et pour pratiquer LINK ! voici la méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public static IEnumerable<Annee>QueryAnnee()
        {
            var Query = from a in LivreInit.CAnnees
                        orderby a.NomAnnee
                        select new { a.NomAnnee };
        }

Je souhaite à partir de là retourner le résultat de ma requête dans une liste afin de pouvoir l'utiliser comme bon me semble ! dans un listview par exemple
J'ai cherché dans les docs et sur le net des exemples, mais tous les exemples se terminent par un foreach et Console.Writeline pour afficher les données
n'étant pas à l'aise avec les collections, une personne pourrait t'elle m'expliquer comment je peux récupérer les données de ma méthode et donc de ma requête
par avance je vous remercie de votre aide
Cordialement

[Edit]
J'ai trouvé ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    public IEnumerable<Annee> QueryAnnee()
         {
             var Query = from a in LivreInit.CAnnees
                         orderby a.NomAnnee
                         select a;
 
             return Query.OfType<Annee>().ToList<Annee>();
         }

Mais je ne sais pas si c'est vraiment conforme à la façon de faire habituel

[Pol63]

une collection c'est un peu comme un tableau, ca stocke x choses
linq permet de faire l'équivalent d'une boucle en une seule ligne, avec une syntaxe proche d'sql server

en effet pour avoir une collection qui ne contient que les controles de type textbox on pourrait écrire
déclaration newlist de type list<textbox>
pour chaque control dans this.controls
si le control est de type textbox alors on l'ajoute (cast) dans newlist
fin boucle

avec linq ca donnerait un truc du genre
newlist = from c in this.Controls where gettype(c) is textbox select c

mauvais exemple car oftype sert à ca mais c'est le principe

donc ta question ne doit pas porter sur linq si tu ne sais pas quoi faire du résultat
parce que console.writeline ou this.Treeview1.nodes.Add c'est la même chose, il y a un for each autour

[patamuche]

Merci pour votre réponse
Je considère à tord ou à raison que IE1numerable est un peu plus qu'une collection de List<>
D'ailleurs on alimente pas une collection de ce type par Add !
Et la requête de type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IEnumerable<Anne>

retourne un type Anonyme, si j'en croit ce que j'ai lu
Mais ce que j'ai fait fonctionne
Cela dit des exemples peut être plus concret sur les comptabilités entre type de collection serait le bienvenu
Surtout que cela n'est pas toujours évident à bien cerner
Merci encore pour votre réponse
Cordialement

[Pol63]

list hérite de inumerable
ienumerable c'est une collection dans laquelle on peut lire
dans list on peut aussi ajouter

linq retourne toujours un ienumerable

l'ienumerable (enfin je pense que ca vient de lui) a un avantage parfois interressant, c'est que sont contenu n'est pas calculé au moment où il est exécuté, mais quand il est lu
autrement dit quand on utilise un for each, .count, .tolist ou autre accès

linq retourne un ienumerable pour qu'on puisse faire d'autre opérations et à mon avis il fait tout en un seul passage au final
(genre faire 3x .where, et au final il ne fera qu'une boucle)

après on peut faire .tolist si on veut récupérer la possibilité d'ajouter


après ce que tu as écris, je ne pense qu'on puisse l'écrire en vb.net (ce que j'utilise) donc je ne pourrais t'en dire plus sur l'utilisation de type anonyme avec une portée telle
quand j'utilise un type anonyme, c'est au sein d'un membre, ca n'en sort pas, car c'est peu pratique (du moins en vb.net)
si en c# on peut les propager c'est plus interressant

[patamuche]

Disons qu'après avoir lu un certains nombre d'ouvrage sur les collections, j'ai été un peu pris de cours sur le typage des collections
Sur les sites Américains il est dit :
1) On utilise var quand on ne connaît pas la structure des données à traiter
2) On utilise IEnumerable<Type> quand on connaît la structure du type a traiter
Dans mon exemple et même si C# utilise toujours le type anonyme pour ses requêtes
ma méthode était on ne peut plus typée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public static IEnumerable<Annee>QueryAnnee()
        {
            var Query = from a in LivreInit.CAnnees
                        orderby a.NomAnnee
                        select new { a.NomAnnee };
        }

Et mon propos donc était de dire que si j'écris un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

List<Annee>Malist=new List<Annee>

pour récupérer le résultat de ma requête et
bien cela provoque un incompatible type !
Je ne sais d'ailleurs toujours pas comment faire
car ma requête dans le cas présent est récupérée dans control ObjectSource qui doit sans doute gérer le pbs!
En tout les cas merci de vos explications qui aurais tendances a confirmer que les conversions de type en C# sur les collections ne sont pas évidentes

[Pol63]

pour mettre un ienumerable dans un list il suffit de faire .ToList sur l'ienumerable
par contre un type anonyme c'est utile quand on a plusieurs informations à stocker, mais ca peut poser des problèmes, aussi en général on écrit une classe pour stocker les valeurs dans des propriétés (une classe anonyme n'est qu'une classe qu'on a pas écrit)

donc faire un select new { a.NomAnnee } causera plus de problèmes qu'un simple select a.NomAnnee où la le typage est évident et le .ToList fonctionnera

et je ne confirme en rien que les conversions en c# sont compliquées
c'est juste qu'il faut éviter le select new{} qui ne permet pas grand chose à part un for each

avec un select a à la place de select a.NomAnnee tu as le même order by de fait, mais tu gardes les instances complètes après tri, ce qui est plus pratique dans la plupart des cas

[patamuche]

Je ne sais pas si vous avez lu l'excellent article de Johann Blais : Link to objets - l'envers du décors (que vous pouvez trouver sur ce site).
Johann Blais nous demontre avec l'outil reflector que les requêtes link par C# sont traitées par des délégués pointant sur des méthodes anonymes !
Cela n'est pas un choix de notre part, mais une façon de faire du compilateur !
Exemple :
1) Une simple liste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
List<Produit> mesProduits = new List<Produit> {
new Produit { Nom = "Pinceau", Categorie = "Bricolage" },
new Produit { Nom = "Seau", Categorie = "Jardinage" },
new Produit { Nom = "Pelle", Categorie = "Jardinage" },
new Produit { Nom = "Ciseaux", Categorie = "Décoration" },
new Produit { Nom = "Tournevis", Categorie = "Bricolage" },
new Produit { Nom = "Feutre", Categorie = "Décoration" },
new Produit { Nom = "Peinture", Categorie = "Décoration" }
}

2) Une classe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
class Produit
{
public String Nom { get; set; }
public String Categorie { get; set; }
}

3) Une très requête dans le Main

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
static void Main(string[] args)
{
var liste = from prod in mesProduits
select prod.Nom;
}

Voici en fait la façon dont le compilateur C# traite la requete :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
private static void Main(string[] args)
{
IEnumerable<string> liste;
liste = Enumerable.Select<Produit, string>(mesProduits,
(CS$<>9__CachedAnonymousMethodDelegate1 != null) ?
CS$<>9__CachedAnonymousMethodDelegate1 :
(CS$<>9__CachedAnonymousMethodDelegate1 = new
Func<Produit, string>(Program.<Main>b__0)));
return;
}

En voit très clairement la confirmation de ses propos
Quand au mot clé new il est comme l'explique Johann Blais dans son article obligatoire en fonction de la complexité de la requête
Je terminerais par ce que disait Jon Skeet dans son livre C# in Depth, c'est à la fois très élégant et un peu lourd !!
Je partage pleinement son point de vu
En tout les cas merci pour vos lumières et vos conseils
je les prends en compte pour le futur
Cordialement

[Pol63]

topic étrange quand même
je ne sais pas trop où on va ...

je ne vois pas de rapport entre ce qu'on a dit précédemment et le fait que linq utilise des méthodes anonymes
c'est très bien les méthodes anonymes, c'est plus utilisable que les types anonymes en tout cas