Discussion :

[CUCARACHA]

Salut,

Je dois effectuer un filtre en cascade sur une vue dont chaque champ est le résultat d'une requête XQuery.

La vue permet d'occulter l'XML.

J'ai mappé ma vue à EF.

Chaque colonne de ma vue a un Nom qui est utilisé dans une table de conditions (KeyValuePair<string,string>)

J'ai chargé l'ensemble de mes éléments une première fois.
J'aimerais arriver à faire un truc du style :

Code :

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

1
2
3
4
5
6
 
foreach (var oCondition in lstConditions) {
    switch (oCondition.Key.Nom) { 
         maVue = maVue.Where(unItem.DontLeChamps[oCondition.Key]==oCondition.Value);
    }
}

Je suis pratiquement certain que c'est possible mais je ne trouve pas la syntaxe.

En cherchant je suis tombé sur
http://developers.de/blogs/andreas_l...framework.aspx

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
   1: Dictionary<string, string> props = new Dictionary<string, string>();
   2: props.Add("PropA", "abc");
   3: props.Add("PropB", "cde");
   4:  
   5: using (EFTestEntities context = new EFTestEntities())
   6: {
   7:     var items = from item in context.TItem.Include("TItemProp")
   8:                 select item;
   9:  
  10:     foreach (var prop in props)
  11:     {
  12:         items = items.Where(i => (i.TItemProp.Count(ip => ip.PropKey == prop.Key && ip.PropValue == prop.Value)) > 0);
  13:     }
  14:  
  15:     return items.ToList();
  16: }

Mais je n'arrive pas à l'appliquer à mon cas.

Ca vous parle ?

D'avance merci

Laurent

[Louis-Guillaume Morand]

moi j'y connais rien, mais justement, il me semble que là où t'as des expressions lambda, tu peux utiliser des méthodes pour "contruire" cet arbre.

tu gardes donc sensiblement le même principe de boucle mais tu génère une expression lambda à la volée (comme un StringBuilder en vulgarisant à mort), puis tu la place dans ton Where(exp_lambda).



ps: le lien que tu donnes ne sembles pas correspondre à ton cas. si tu regardes bien PropKey est un membre de la classe. c'est-à-dire que tes filtres à toi, taperaient toujours sur le même membre de ton objet. Or je suis convaincu que c'est pas ce que tu veux faire car ca ressemble à une recherche multi-critères ton truc.
Il a pris un mauvais exemple le gus. la seule chose qu'il fait, c'est tester le nom et le prenom de l'objet par exemple, mais avec des valeurs différentes. je sais pas si je suis clair :/

[CUCARACHA]

Au risque de passer pour une buse dont le niveau intellectuel qui rivaliserait avec celui d'une méduse desséchée, je ne connais pas ces lambda expressions...
C'est sans doute pourquoi tout n'est pas encore très clair le Linq to Entity pour moi...
Je vais bucher la chose, mais si tu connais des raccourcis, je suis preneur...

++

Laurent

[Louis-Guillaume Morand]

on a qu'à lancer le club des buses. J'ai écrit ma première requête linq (avec EF) y a 6 jours. je suis encore plus pourri que toi sur ce coup

je me rappelle juste la demo de Mitsu sur le C# avancé aux techdays où il editait une expression lambda pour modifier un calcul je crois.
ce lien pourrait p-e t'aider
http://msdn.microsoft.com/en-us/library/bb882637.aspx

après il suffira pas, mais en gros, l'idée est de représenter le filtre par une expression lamdba, expression à laquelle tu peux greffer des "branches", pour former une expression finale qui te servira de filtre.

[CUCARACHA]

Salut,

Merci, déjà que c'était fatigant, là ça donne carrément mal à la tête. En plus cet aprèm j'ai codé une proc stock, j'ai noté que j'étais un peu rouillé à cause de ces 4 mois d'EF (Attention de ne pas tout oublier quand même).

Le truc qui me bluffe le plus c'est quand même les .SaveChanges()

Je vais bucher l'exemple que tu m'as passé.

(Je sais que ça ne se fait pas trop de dire ça mais je trouve que ça manque une rubrique EF dans C# et dans VB. C'est vrai qu'il faut des contributeurs mais c'est vraiement une techno qui monte, comme MVC).

++

Laurent

[Louis-Guillaume Morand]

le sous-forum sera fait en temps et en heure . Pour le moment, il y a les tags, et ils sont bien suffisants. ca a été discuté et tant que ce n'est pas assez utilisé, c'est plus gênant pour les utilisateurs d'avoir trop de sous-forums.

[Arnard]

Hello,
mettre des mots français purs n'aide pas, tu pourrais mettre un nom de propriété (mode titilleux), et aussi un jeu de données associé, histoire de se faire une idée plus précise du bouiboui ?

sinon, à première vue, je dirais :

Code :

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

1
2
3
4
5
foreach (var oCondition in lstConditions) {
    switch (oCondition.Key.Nom) { 
         maVue = maVue.Where(unItem => unItem.DontLeChamps[oCondition.Key]==oCondition.Value);
    }
}

mais sans un jeu de données, je ne garantis rien !!

Si tu as déjà essayé ça, tu as une erreur à la compilation ou à l'exécution ?

[CUCARACHA]

Salut,

en fait, compte tenu des délais que j'avais pour réaliser le filtre, j'ai fait une solution en construisant une chaine de requête SQL que je maîtrise beaucoup mieux.

Le truc c'est que pour accéder à une propriété par son nom sous forme de chaine (sauf erreur de ma part) il me semble qu'il faut utiliser la réflexion. J'ai commencé à explorer cette voie, je reprendrais cette exploration après que nous ayons terminé la livraison de la phase 1 de notre projet. J'ai pris de l'avance dans d'autres parties du projet afin de libérer du temps pour ce filtre générique.

Je reprendrais cette discussion au retour de mes vacances, c'est à dire, début octobre.

++

Laurent

[Arnard]

S'il s'agit de retrouver une propriété par son nom, alors oui c'est réflexion. Mais c'est assez étrange comme architecture