Vous connaissez LINQ to Object, LINQ to Dataset, LINQ to XML, etc... Microsoft livre déjà une large palette de fournisseurs de données (providers) pour LINQ. Dans sa grande sagesse Microsoft a aussi publié les spécifications (et des exemples) permettant à tous de développer des fournisseurs de données pouvant fonctionner avec LINQ. Cette ouverture extraordinaire permet d'interroger avec LINQ des données de toute sorte sans avoir besoin de les transformer au préalable.
Mais savez-vous qu'à ce jour il existe déjà plus d'une trentaine de providers LINQ ? Et que forcément certains vous rendrons des services inestimables, à condition d'en connaître l'existence... Vous pouvez même écrire vos propres providers LINQ ! Je vous conseille d'ailleurs cette page du Wayward blog qui propose une série de billets expliquant comment créer un tel provider.
Un exemple parmi tant d'autres pour illustrer le propos : LINQ To Amazon. Il permet tout simplement d'interroger directement Amazon pour sélectionner des livres selon autant de critères que nécessaire, et sans autre programmation qu'une requête LINQ. Fantastique non ? Un petit exemple pour concrétiser la chose :
var query =
from book in new Amazon.BookSearch()
where
book.Title.Contains("ajax") &&
(book.Publisher == "Manning") &&
(book.Price <= 25) &&
(book.Condition == BookCondition.New)
select book;
Cool non ? LINQ to Amazon est présenté dans le livre LINQ in Action (que je vous conseille au passage) et vous pouvez accéder au blog de Fabrice qui le présente.
Mais cela n'est qu'un exemple, et il existe bien d'autres fournisseurs de données LINQ, en voici une liste (avec liens - shift clic pour les ouvrir dans une nouvelle fenêtre) :
Charlie Calvert, que les delphistes connaissent bien, et qui comme bon nombre des meilleurs a depuis longtemps choisi la voie .NET avec Microsoft, met à jour régulièrement cette liste qui est issue de son blog. Si vous lisez l'anglais, bookmarquez la page Links to LINQ de son blog qui, en plus de la liste des providers, fournit de nombreux liens en rapport avec cette technologie.
Conclusion
LINQ est une technologie fantastique dont je ne cesse de dire du bien (et d'utiliser avec bonheur dans la totalité des applications que j'écris), je ne peux imaginer utiliser demain ou dans 10 ans un langage qui n'implémentera pas une feature de même type. LINQ to "n'importe quoi" est la preuve que cette technologie est en plus ouverte et que seule notre imagination est la limite. Borland utilisait le slogan "the sky is the limit" durant ses grandes années de gloire. Microsoft ne le dit pas, mais la firme de Redmond rend ce rêve possible aujourd'hui...
Il arrive souvent (ou il devrait souvent arriver...) qu'on veuille tester rapidement du code. Par exemple vérifier qu'une méthode retourne bien le bon résultat selon deux ou trois variantes des paramètres d'entrée. Mais écrire du code de test à chaque fois, même si "on devrait" le faire tout le temps, n'est pas totalement conforme à la réalité. On a plus souvent la pression que la bride sur le collier et cela impose de travailler bien, mais vite ! Plus...
Qu'il s'agisse de LINQ to Object ou LINQ to SQL il serait bien agréable de pouvoir disposer d'une sorte de bloc-note pour tester ou mettre au point des requêtes, voire pour s'entraîner tout simplement. Pouvoir gérer les connexions aux bases de données, éventuellement envoyer et tester du SQL "de base" sur celles-ci serait la cerise sur la gâteau. Et bien cet outil existe, et en plus il est gratuit !
LINQPad, puisque c'est de lui qu'il s'agit, n'est pas vraiment une nouveauté absolue mais il y a fort à parier que nombre d'entre vous n'en ont jamais entendu parlé.
Cet outil a été développé conjointement à l'excellent ouvrage "C# 3.0 in a nutshell" de Joseph Albahari, un australien, qui par la diffusion gratuite de LINQPad tente une promo plutôt positive de son livre et de ses services de consulting (si on habite au pays des kangourous, of course).
J'aime personnellement cette idée de "pub positive" qui consiste à offrir de son temps et de son travail pour faire sa pub plutôt que de gaver les gens de bandeaux agaçants. C'est de la pub dans un esprit totalement anti-google (de la pub pour de la pub, partout, sans rien apporter à ceux qui la subissent), et il faut encourager ceux qui adoptent cette façon respectueuse de faire leur promotion. Achetez le livre de Joseph ! Fin de la paranthèse :-)
LINQPad est ainsi un super utilitaire. Il interprète du code C# ou VB et les requêtes LINQ to Object ou LINQ to SQL. Il autorise la connexion à des bases de données, offre un éditeur purement SQL en supplément, bien pratique, et il permet même d'ajouter ses propres DLL et ses propres espaces de noms pour qu'ils soient reconnus dans le code C# qu'on tape !
On peut dès lors utiliser LINQPad pour requêter des objets métiers complexes, un framework maison, un modèle LINQ to SQL, etc.. Il suffit d'ajouter les références.
Pour terminer, LINQPad est fourni avec de nombreux exemples qui sont autant de moyens de tester ses connaissances et d'apprendre les subtilités de LINQ. Utilisé conjointement à ma version des "101 exemples LINQ" de Microsoft, LINQPad devient un fantastique outil d'auto-formation.
Pour télécharger le produit et avoir accès aussi aux forums, aux vidéos de démo, et plein d'autres choses, aller sur la page de LINQPad !
Bon Dev...
Et Stay Tuned !
Les expressions Lambda ont été introduites dans C# 3.0. Utilisées correctement, tout comme LINQ to Object, elles permettent une grande simplification du code entraînant dans un cercle vertueux une meilleure lisibilité de ce dernier favorisant maintenabilité et fiabilité de ce même code. Il n'y a donc aucune raison de rester "frileux" vis à vis de cette nouveauté syntaxique comme encore trop de développeurs que je rencontre dans mes formations ou ailleurs.
Pour démontrer cette souplesse, voici un petit exemple qui valide un document XML en fonction d'un schéma.
La méthode Validate() de la classe XDocument attend en paramètre un delegate de type ValidationEventHandler. Dans un code très court il n'est pas forcément judicieux de déclarer une méthode juste pour passer son nom en paramètre à Validate(). Les "sous procédures" ou procédures imbriquées de Pascal n'existent pas en C# et l'obligation de déclarer à chaque fois des méthodes private pour décomposer la moindre action est une lourdeur syntaxique de ce langage dont on aimerait se passer parfois (une méthode même private est visible par toutes les autres méthodes de la classe ce qui n'est pas toujours souhaitable. Seules les méthodes imbriquées de Pascal sont des "méthodes privées de méthodes").
En fin de billet vous trouverez d'ailleurs le lien vers un autre billet dans lequel j'explique comment utiliser les expressions Lambda en les nommant pour retrouver la souplesse des procédures imbriquées. Même si "l'astuce" présentée ici peut y ressembler dans l'esprit, dans la pratique les choses sont assez différentes puisque nous n'utiliserons pas une expression nommée.
Revenons à l'exemple, il s'agit de valider un document XML à partir d'un schéma. Et de le faire de la façon la plus simple possible, c'est à dire en évitant l'écriture d'un delegate, donc en utilisant directement une expression Lambda en paramètre de Validate().
Supposons que nous ayons déjà le schéma (variable schema) et le document XML (variable doc), l'appel à Validate pourra donc s'écrire :
doc.Validate(schema,(obj, e) => errors += e.Message + Environment.NewLine);
"errors" est déclarée comme une chaîne de caractères. A chaque éventuelle erreur détectée par la validation l'expression concatène le message d'erreur à cette dernière. En fin de validation il suffit d'afficher errors pour avoir la liste des erreurs. Mais cela n'est qu'un exemple d'utilisation de l'expression Lambda. Ce qui compte c'est bien entendu de comprendre l'utilisation de cette dernière en place et lieu d'un delegate de tout type, ici ValidationEventHandler d'où les paramètres (obj,e) puisque ce delegate est déclaré de cette façon (un objet et un argument spécifique à cet handler).
C'est simple, nul besoin de déclarer un gestionnaire d'événement donc une méthode avec un nom et une visibilité. On évite que cette méthode soit réutilisée dans le code de la classe considérée (si elle existe on est tenté de la réutiliser mais sa stratégie d'écriture n'est pas forcément adaptée à une telle utilisation d'où possible bug), etc. Que des avantages donc.
Pour plus d'information vous pouvez lire mon article sur les nouveautés syntaxiques de C# 3.0 ainsi que mon billet montrant comment retrouver en C# le bénéfice des procédures imbriquées de Pascal grâce aux expressions Lambda.
Si vous voulez jouez avec l'exemple, vous pouvez télécharger le projet VS 2008 qui montre tout cela : lambda.zip (21,71 kb)
Clone Detective pour Visual Studio est un outil de debug un peu particulier puisqu'il ne cherche pas les bugs mais les redondances de code. 
Plus...