Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Florent — Thu, 26 Jul 2007 02:35:20 GMT

J'ai proposé:

Créér une liste de Customers intermédiaire pour faire une copie en mémoire de la requête issue de l'objet métier.

List<Customer> GetCustomer() { return q.ToList(); }

Pour pouvoir ensuite la manipuler et la filtrer librement avec un .FindAll et un jolie predicate.

Mais tu m'as dit que c'était pas la meilleure solution :)

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Mitsu — Thu, 26 Jul 2007 07:38:03 GMT

En effet, peupler une collection une fois pour toute en parcourant l'énumération nous fait quitter le monde de Linq to Sql pour se retrouver avec une simple collection mémoire et toute l'artillerie de Linq to Objects. C'est donc UNE solution.

Cependant, retarder l'exécution de la requête à travers toutes les couches de l'architecture reste très tentant et bien plus efficace au niveau des objects alloués.

Donc en effet, on peut faire mieux.

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Matthieu MEZIL — Thu, 26 Jul 2007 11:01:57 GMT

private IQueryable<Customer> GetCustomersQueryable()

{

return

from c in dc.Customers

select c;

}

public IEnumerable<Customer> GetCustomers()

{

return GetCustomersQueryable().AsEnumerable();

}

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Matthieu MEZIL — Thu, 26 Jul 2007 12:29:58 GMT

Florent, je repensais à ton histoire de liste.

Tu auras un autre problème avec ta liste. Si les données de ta BD sont modifiées, ta liste ne sera plus à jour alors qu'avec une Query si.

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Simon — Thu, 26 Jul 2007 14:32:40 GMT

Attention, y'a un piège Matthieu ^^

C'est presque ca.

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Mitsu — Thu, 26 Jul 2007 18:23:21 GMT

En effet Matthieu,

Ton code fonctionne bien car désormais les extensions sur GetCustomers() seront bien en mémoire mais cette couche est mal isolée car rien ne m'empêche de recaster en IQueryable.

var q = GetCustomer() as IQueryable<Customer>;

q.Where(...); //sql à nouveau.

La solution de Florent, isole bien Linq to Sql car List<Customer> n'est plus un IQueryable.

La solution est à mi-chemin

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Matthieu MEZIL — Thu, 26 Jul 2007 19:25:58 GMT

ok et comme ça ?

private IQueryable<Customer> GetCustomersQueryable()

{

return

from c in dc.Customers

select c;

}

public IEnumerable<Customer> GetCustomers()

{

foreach (Customer c in GetCustomersQueryable())

yield return c;

}

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Mitsu — Thu, 26 Jul 2007 21:06:21 GMT

Good point !!

C'est en effet la solution.

IEnumerable<Customer> GetCustomers()

{

var q =

from c in dc.Customers

select c;

return

from c in q.AsEnumerable()

select c;

}

Le fait de réécrire l'itérateur génère une nouvelle classe qui implémente uniqueme IEnumerable<T> sans être IQueryable<T>. Le code est légèrement plus conséquent puis qu'il y a un itérateur supplémentaire mais nous conservons les avantages de l'exécution tardive de la requête sans créer de collection intermédiaire.

Qui veut encore des Quizz ? :p

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Florent — Thu, 26 Jul 2007 21:24:07 GMT

Next please!

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Simon — Thu, 26 Jul 2007 21:31:31 GMT

Ouais, des quizz, je veux des quizz bien tordus ! ^^

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Thomas Lebrun — Fri, 27 Jul 2007 10:24:01 GMT

Pas mal: j'était partit sur la même première idée que Matthieu. Comme quoi, faut faire attention :)

Allez Mitsu, des quizz, des quizz !! :)

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Matthieu MEZIL — Fri, 27 Jul 2007 12:38:51 GMT

Les quizz sont super intéressants car ils permettent de confronter les différentes idées personnes qui y participent et, de plus, ils permettent de progresser avec des questions dont on ignore la réponse. Donc oui 100% pour que tu continues dans ce sens. :)

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Matthieu MEZIL — Fri, 27 Jul 2007 18:27:10 GMT

A mon tour de lancer un quizz : http://blog.developpez.com/index.php?blog=121&title=a_mon_tour_de_lancer_un_quizz&more=1&c=1&tb=1&pb=1

Geek quizz !

Mitsuru FURUTA - Microsoft FRANCE — Thu, 16 Aug 2007 18:32:25 GMT

Petite question amusante sur C# 3: Le framework 3.5 apporte la méthode AsEnumerable. Quel est donc l'intérêt

re: Geek quizz II: comment stopper l'imbrication des expressions Linq to Sql ?

Nicolas Lehuen — Sat, 31 Oct 2009 09:22:16 GMT

Salut Mitsu,

Des heures de discussion avec Daniel G. sur ce sujet... Faut-il ou ne faut-il pas isoler les deux mondes ? Si la couche de présentation fait du Linq, soit elle se retrouve à construire des requêtes SQL sans le savoir, soit elle se retrouve à filtrer des énumérations, c'est à dire à refaire côté présentation du travail que devrait faire la BDD, avec tout ce que ça veut dire en terme de perfs...

Ton astuce de reconstruire un itérateur au lieu de tout monter en mémoire est déjà un grand progrès. Mais dans ton exemple, mettons que le premier client habitant à Londres soit le 1 000 001 ème de la table ; en isolant on perd l'intelligence de la BDD, la possibilité d'utiliser un index de la BDD, on se retrouve à parcourir un million d'enregistrement avec tout ce que ça veut dire comme transfert entre la BDD et le serveur de présentation. Pour moi c'est bien plus nuisible qu'une brèche dans la sacro-sainte isolation entre le M et le V du MVC.

Alors évidemment, la solution c'est de n'exposer à la couche de présentation que des énumérateurs "petits", c'est à dire prémacher le travail dans la couche métier de manière à ce qu'en aucun cas la couche de présentation ne se retrouve à devoir itérer sur de gros jeux de résultats. Mais au final je suis super admiratif de ce que Microsoft a fait avec Linq (à des années lumière de ce qu'on trouve côté Java, oui c'est moi qui dit ça) et je trouve dommage de se priver de ses capacités.

Sur le projet sur lequel nous travaillons actuellement avec Daniel, le client impose l'utilisation de procédures stockées pour accéder à la BDD, ce qui tranche le débat (interdit de générer des requêtes à la volée), mais dans un monde plus libre, à tout prendre, je préfèrerais ne pas isoler et manipuler directement l'ObjectQuery, avec toute la puissance que cela induit. Ou alors il faut interdire carrément l'utilisation de Linq dans la couche de présentation pour éviter le genre de problème indiqué ci-dessus :)

Nicolas