Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Les class Helpers, enfer ou paradis ?

Class Helpers 

Les class helpers sont une nouvelle feature du langage C# 3.0 (voir mon billet et mon article sur les nouveautés de C# 3.0).

Pour résumer il s'agit de "décorer" une classe existante avec de nouvelles méthodes sans modifier le code de cette classe, les méthodes en questions étant implémentées dans une autre classe.

Le principe lui-même n'est pas récent puisque Borland l'avait "inventé" pour Delphi 8.Net (la première version de Delphi sous .Net) afin de permettre l'ajout des méthodes de TObject à System.Object (qu'ils ne pouvaient pas modifier bien entendu) afin que la VCL puisse être facilement portée sous .Net. Borland avait déposé un brevet pour ce procédé (ils le prétendaient à l'époque en tout cas) et je m'étonne toujours que Microsoft ait pu implémenter exactement la même chose dans C# sans que cela ne fasse de vagues. Un mystère donc, mais là n'est pas la question.

Mauvaises raisons ?

Les deux seules implémentations de cet artifice syntaxique que je connaisse (je ne connais pas tout hélas, si vous en connaissez d'autres n'hésitez pas à le dire en commentaire que l'on puisse comparer) sont donc celle de Borland dans Delphi 8 pour simplifier le portage de la VCL sous .NET et celle de Microsoft dans C# pour faciliter l'intégration de Linq dans le langage.

Deux exemples, deux fois pour la même raison un peu spécieuse à mes yeux : simplifier le boulot du concepteur du langage pour supporter de nouvelles features. Deux fois une mauvaise raison à mes yeux, un peu trop puristes peut-être, qui pensent qu'un élément syntaxique doit se justifier d'une façon plus forte, plus théorique que simplement "pratique".

Résultat, je me suis toujours méfié des class helpers car leur danger est qu'un objet se trouve d'un seul coup affublé de méthodes "sorties d'un chapeau", c'est à dire qu'il semble exposer des méthodes publiques qui ne sont nulles part dans son code. J'ai horreur de ce genre de combines qui, à mon sens, favorise un code immaintenable. Si j'adore la magie, à voir ou à pratiquer, je la déteste lorsque je porte ma casquette d'informaticien... J'ai donc toujours conseillé la plus grande circonspection vis à vis de cet artifice syntaxique, que ce soit à l'époque (déjà lointaine.. le temp passe!) où je faisais du Delphi que maintenant sous C# qui vient d'ajouter cette fioriture à sa palette.

Jusqu'à aujourd'hui, faute d'avoir trouver une utilisation intelligente des class helpers qui ne puissent être mise en oeuvre plus "proprement", les class helpers étaient à mon sens plutôt à classer du côté enfer que paradis. Interface et héritage m'ont toujours semblé une solution préférable à ces méthodes fantomes.

Trouver une justification

Mais il n'y a que les imbéciles qui ne changent pas d'avis, n'est-ce pas... Et je cherche malgré tout toujours à trouver une utilité à un outil même si je le trouve inutile de prime abord, réflexe d'ingénieur qui aime trouver une place à toute chose certainement.
J'ai ainsi essayé plusieurs fois dans des projets de voir si les class helpers pouvaient rendre de vrais services avec une réelle justification, c'est à dire sans être un cache misère ni une façon paresseuse de modifier une classe sans la modifier tout en la modifiant...

Comme j'ai enfin trouvé quelques cas (rares certes) dans lesquels les class helpers me semblent avoir une justification pratique, je me suis dit que vous en toucher deux mots pourraient éventuellement faire avancer votre propre réflexion sur le sujet (même si j'ai bien conscience que je dois être assez seul à me torturer la cervelle pour trouver absolument une utilité aux class helpers :-) ).

Bref, passons à la pratique.

Un cas pratique

Premier cas, les chaînes de caractères. Voilà un type de données vieux comme la programmation qui pourrait être un bon candidat à l'exploitation des possibilités des class helpers. En effet, hors de question de dériver la classe System.String et encore moins de pouvoir modifier le mot clé "string" de C#. Pourtant nous utilisons très souvent les mêmes fonctions "personnelles" sur les chaînes de caractères d'un même projet.

Par exemple, j'ai pour principe que les chaînes exposées par une classe (propriétés de type string donc) ne soient jamais à null. De ce fait, dans toutes les classes qui exposent un string, j'ai, dans le setter, la même séquence qui change l'éventuel null de value à string.Empty. C'est assez casse-pieds à répéter comme ça mécaniquement dans toutes les propriétés string de toutes les classes.

Et là, pas de possibilité de faire supporter une interface à System.String, ni de la dériver comme je le disais plus haut. C'est ici que les class helpers peuvent trouver une première justification pratique pour le développeur en dehors d'avoir facilité la vie à MS pour implémenter Linq.

Prenons le code suivant que nous plaçons dans une unité "Tools" de notre projet :

public static class Utilities
{

     public static string NotNullString(this string s)
      { 
return !string.IsNullOrEmpty(s) ? s.Trim() : string.Empty; }
...
 }

La classe Utilities est une classe statique qui contient tous les petits bouts de code utilisables dans tout le projet. Parmi ces méthodes, on voit ici l'implémentation du class helper "NotNullString". D'après cette dernière, la méthode ne sera visible que sur les instances de la classe "string". Le code lui-même est d'une grande simplicité puisqu'il teste si la chaîne en question est vide ou non, et, selon le cas, retourne string.Empty ou bien un Trim() de la chaîne. J'aime bien faire aussi systématiquement un Trim() sur toutes les propriétés string, je trouve ça plus propre surtout si on doit tester des équalités et que les chaînes proviennent de saisies utilisateurs.

Dans la pratique il suffira maintenant n'importe où dans notre projet d'écrire la chose suivante pour être certain qu'à la sortie de l'affectation la chaîne résultante ne sera jamais nulle et qu'elle ne comportera jamais d'espaces en trop en début ou en fin :

public string BusinessID
{  
get { return _BusinessID; }
    
set if (value != _BusinessID)
            
{ _BusinessID = value.NotNullString().ToUpperInvariant();
                
DoChange("BusinessID");
            
}
         
}
}

On voit ici une propriété string "BusinessID" qui, dans son setter, utilise désormais la nouvelle méthode fantome de la classe string... En fin de séquence nous sommes certains que _BusinessID est soit vide, soit contient un chaîne sans espace de tête ou de queue (et qu'elle est en majuscules, en plus dans cet exemple).

Voici donc une première utilisation "intelligente" des class helpers, la décoration d'une classe du framework (ou d'une lib dont on n'a pas le code source) pour lui ajouter un comportement, éventuellement complexe, dont on a souvent l'utilité dans un projet donné.

On pourrait penser ainsi à une fonction "ProperCase" qui passe automatiquement la casse d'une chaîne en mode "nom de famille", c'est à dire première lettre de chaque mot en majuscule, le reste en minuscule, ou à bien d'autres traitements qu'on aurait besoin d'appliquer souvent à des chaînes dans un projet.

Encore un autre cas

Dans la même veine, une application doit souvent manipuler des données issues d'une base de données et les modifier (en plus d'en insérer de nouvelles). On le sait moins (mais on s'aperçoit vite quand cela bug!) que le framework .NET possède, pour les dates par exemple, ses propres mini et maxi qui ne sont pas compatibles à toutes les bases de données, notamment SQL Server. Si vous attribuer à une date la valeur DateTime.MinValue et que vous essayez d'insérer cette dernière dans un champ Date d'une base SQL Server vous obtiendrez une exception de la part du serveur : la date passée n'est pas dans la fourchette acceptée par le serveur.
Dommage... DateTime.MinValue est bien pratique...

On peut bien entendu fixer une constante dans son projet et l'utiliser en place et lieu de DateTime.MinValue. Voci un exemple pour MaxValue (le problème étant le même):

DateTime MaxiDate = new DateTime(3000, 1, 1, 0, 0, 0);

Il suffira donc d'utiliser MaxiDate à la place de DateTime.MaxValue. La date considérée comme "maxi" est ici arbitraire (comme on le ferait pour la date mini) et est choisie pour représenter une valeur acceptable à la fois pour l'application et pour la base de données. Ici on notera que je prépare le terrain pour le bug de l'an 3000. Moins stupide qu'un coboliste et le bug de l'an 2000, vous remarquerez que je me suis arrangé ne plus être joignable à la date du bug et que mes héritiers sont aussi à l'abris de poursuites judiciaires pour quelques siècles :-)

L'utilisation d'une constante n'a rien de "sale" ou de "moche", c'est un procédé classique en programmation, même la plus éthérée et la plus sophistiquée. Toutefois, Puisque DateTime existe, puisque DateTime est un type complexe (une classe) et non pas un simple emplacement mémoire (comme les types de base en Pascal par exemple), puisque cette classe expose déjà des méthodes, dont Min et MaxValue, il serait finalement plus "linéaire" et plus cohérent d'ajouter notre propre MaxValue à cette dernière en place et lieu d'une constante.

Encore un bon exemple d'utilisation des class helpers. Ici nous homogénéisons notre style de programmation en évitant le mélange entre méthodes de DateTime et utilisation d'une constante. De plus, en ajoutant une méthode spécifique à DateTime, celle-ci sera visible par Intellisense come membre de DateTime, ce qui ne serait pas le cas de la constante. 

Dans la même classe Utilities nous trouverons ainsi :

public static DateTime SQLMaxValue(this DateTime d)
{
return new DateTime(3000, 1, 1, 0, 0, 0); }

 Et nous voici avec la possibilité d'écrire : MaDate = DateTime.SQLMaxValue();

Conclusion

Enfer ou paradis ? Les class helpers, comme tout artifice syntaxique peuvent se ranger dans les deux catégories, ils ne sont qu'un outil à la disposition du développeur. Un simple marteau peut servir à bâtir une maison où vivre heureux ou bien à assassiner sauvagement son voisin...  Les objets inanimés n'ont pas de conscience, ou plutôt, si, ils en ont une : celle de celui qui les utilise. A chacun d'utiliser les outils que la technologie humaine met à sa disposition pour créer un enfer ou un paradis...

Techniquement, je n'enfoncerai pas les portes ouvertes en donnant l'impression d'avoir découvert une utilisation miraculeuse des class helpers. Cela serait stupide, puisque justement cette syntaxe a été créée par Borland puis MS pour justement décorer des classes dont on ne possède pas le source (pas d'ajout de méthode ni d'interface) et qui ne sont pas héritables. En ajoutant des class helpers à string ou DateTime nous ne faisons rien d'autre que d'utiliser les class helpers exactement en conformité avec ce pour quoi ils ont été créés.

L'intérêt de ce billet se situe alors dans deux objectifs : vous permettre de réfléchir à cette nouveauté de C#3.0 que vous ne connaissez peut-être pas ou mal et vous montrer comment, en pratique, cela peut rendre des services non négligeables.

Si l'un ou l'autre de ces objectifs a été atteint, vous tenez alors votre récompense d'avoir tout lu jusqu'ici, et moi d'avoir écrit ce billet :-)

Stay tuned !

[EDIT: voir cet autre billet plus récent sur les class helpers]

Une révolution technique annonce la mort des interfaces graphiques

En effet, de nombreuses études menées tant par IBM que par SUN montrent que, le chiffre est déroutant de précision, 98,54 % de la puissance d'un ordinateur moderne est consacrée à des tâches qui lui sont propres au lieu de faire ce pour quoi on le paye : le travail de l'utilisateur.

Sans entrer dans les détails de ces études, résumons l'essentiel en indiquant que cette puissance "envolée", voire "volée" par les éditeurs de logiciels du monde entier aux possesseurs de PC, est consacrée en majorité à la gestion de l'interface graphique, tant par l'OS que par les applications dont 82,12% du code est consacré à la gestion des fenêtres et autres artifices graphiques.

Ne parlons pas des dernières modes comme Flash de Adobe ni même de Silverlight de Microsoft et encore moins des interfaces graphiques de Ubuntu ou de Vista, ces "goinfres de Ghz" sont hélas aussi des monstres affamés de Ram !

C'est là que la récente publication d'une équipe de chercheurs du MIT vient troubler la fête de tous ces "gigavores". Le sujet : "A simple and efficient user interface for the future". Ni plus ni moins, ils veulent nous montrer la voie à suivre pour les années à venir afin de concevoir des interfaces utilisateurs efficaces, économes en Ram et en puissance machine. Quel est le secret ?

Difficile de tout expliquer, les concepts sont très novateurs et par force réclament un peu de recul que nous n'avons pas encore pour tout comprendre. On se rappelle du temps qu'il aura fallut aux interfaces à fenêtre pour s'imposer alors que leur création par le PARC de Xerox datait déjà de plusieurs décennies ! Il est bien entendu évident que déjà les débats fusent sur le Web "faut-il réécrire toutes les applications ?", "Cette nouvelle norme sera-t-elle une mode?", etc. Nous en avons l'habitude, toutes les idées nouvelles sont ainsi contestées par l'arrière garde de ceux que nous appelons les "dinosaures"...

En bref, le principe exposé par J. Peter et ses collègues repose sur des principes simples (mais odacieux), notamment en utilisant un affichage constitué d'une matrice de 80 caractères sur 25 lignes contrôlé par un pilote matériel contenant en mémoire morte le dessin des lettres de l'alphabet. Les fondeurs tels qu'Intel et AMD se disent près à fabriquer les nouvelles puces, mais les difficultés techniques sont telles que personne n'osent encore avancer de prix pour ces merveilles.
Du côté de la programmation il semble que les langages les plus modernes prennent un sacré coup de vieux ! En effet, pour contrôler l'interface visuelle, il sera nécessaire de supporter un jeu d'instructions particulier. Des exemples de code illustrent l'article du MIT, on peut y voir des combinaisons de type "GotoLine 25" ou "GotoCol 45" le tout imbriqué dans des appels à une mystérieuse classe appelée "Console".

Des prototypes de PC supportant cette technologie innovante devraient bientôt voir le jour, c'est en tout cas ce que laisse supposer l'air entendu et satisfait qu'affichait le patron d'Apple présent lors de la conférence donnée par J.Peter et ses collègues du MIT.

La mort des interfaces graphiques gourmandes en Ram et en puissance semble bien être pour bientôt... Le progrès ne s'arrête pas, ainsi va le monde.

 

Joyeux 1er avril à tous !

TDD utopie ou géniale avancée ?

Perdu dans mes pensées lors d'une pause amplement méritée je pensais à la méthode TDD et j'ai eu envie de vous livrer le fruit de mes réflexions. Après tout, bloguer c'est ça aussi.
...C'est sûr je vais passer pour un ET, aucun être humain normalement constitué n'irait penser à de telles choses pendant une pause. Mais j'assume !

Le Test-Driven Development ou développement piloté par les tests, n'est pas réellement un sujet récent, cette méthodologie est dérivée du concept "tester en premier" de l'Extreme programming, lui même une forme dérivée de l'Agile Software Development datant de 1996, dans la même veine que Scrum ou RAD en 1991, ce qui ne nous rajeunit pas.
Tout cela pouvant remonter certainement au néolithique de proche en proche. Par exemple taper sur la tête de son voisin avec la massue toute neuve qu'on vient de fabriquer histoire de tester si elle sera assez solide pour aller à la chasse était certainement le grand début de l'Agile ou piquer un silex tout taillé à un copain est finalement le début de la réutilisation voire du RAD. Dieu lui-même en reprenant les plans de fabrication et une côte d'Adam pour faire Eve faisait de la réutilisation et du design pattern. Confondre grand ordonnateur et grand ordinateur est un exercice de style osé, j'en conviens.

Bref le TDD, comme toute méthodologie, n'est que le fruit d'une lente maturation au fil des ans. Et parmi toutes celles proposées ces 20 dernières années c'est celle qui apparaît la plus sage, la mieux adaptée. Elle recentre le développement sur l'essentiel : le besoin réel et donc l'utilisateur. Techniquement elle prône une économie de mouvement évitant les errances : on ne code que ce qui est nécessaire pour que ça marche et surtout pas plus. On s'éloigne ainsi des grandes généralisation, fantasme d'informaticien, donnant lieu à des développements complexes et coûteux qui, une fois terminés, sont déjà obsolètes.

Mais est-ce une nouvelle utopie et subira-t-elle le même sort que toutes les autres méthodes de développement (à savoir se limiter à quelques termes pompeux sur les propositions commerciales et à quelques discussions autour des machines à café) ?

UML est un bon exemple du triste sort réservé aux meilleures idées de nos têtes pensantes. Même si cette mode tend à passer (remplacer par d'autres) il fut un moment ou toute "propal" se devait de faire apparaître ce terme comme toute lessive se doit au minimum d'avoir la mention "deux en un" (voire plus) sur son emballage pour se vendre.

Avant que d'excellentes méthodes comme TDD puissent s'imposer, il sera donc nécessaire de changer les mentalités, celles des dirigeants de SSII et de leurs commerciaux qui se retranchent souvent derrière la loi du marché et de la concurrence pour offrir au client ce qu'il demande au lieu de lui conseiller ce dont il a besoin, et celle des clients qui ne peuvent continuer à se dédouaner de leur ignorance s'ils désirent obtenir des logiciels fiables, maintenables et adaptés à leurs besoins et ce au meilleur prix (mais pas en dessous, la qualité se paye). 

Un long voyage nous attend donc avant qu'un tel bouleversement se produise, et TDD, comme l'XP ou l'Agile development et bien d'autres dont nous avons tous oublié les noms, finira peut-être aussi dans les nymbes brumeuses où s'évanouïssent les idées trop en avance sur les mentalités...

En attendant, essayez de développer selon TDD :  vous y gagnerez en efficace et en qualité.
Visual Studio se plie fort bien au Unit Testing, mais beaucoup moins bien au TDD. Il est fort simple de créer un test pour une méthode existante mais pas l'inverse, base du TDD. Néanmois, avec un peu d'imagination, il est tout à fait possible de créer un squelette de classe, d'y ajouter une méthode ne faisant rien puis de générer le test unitaire pour enfin revenir sur l'implémentation de la méthode. Il n'y a pas de temps perdu, il n'y a qu'à changer un peu l'ordre dans lequel les choses sont faites.

Essayez, vous verrez, c'est étonnant comme le code final d'une classe est assez différent de celui qu'il aurait été créé par la méthode "classique".

Happy coding !

ADO.Net Entity Framework - une série d'articles en US

Stefan Cruysberghs a publié (en anglais) une série de trois articles (récents) sur l'Entity Framework qui proposent un tour d'horizon assez intéressant de cette technologie.
En voici le sommaire (avec accès direct aux articles): 

Part 2 :

Part 3 :

Si vous préférez accéder aux trois articles séparément :

Bonne lecture !

Simplifier l'utilisation des expressions régulières avec Expresso

Les expressions régulières semblent être ignorées par bon nombre de développeurs malgré leur puissance. Une raison à cela : c'est aux antipodes de la programmation moderne qui se veut claire et lisible...

Les expressions régulières c'est un peu comme XSLT, balèze mais incompréhensible à moins de ne faire que ça tous les jours. Le problème avec ces "langages" c'est que justement on n'en a pas besoin tous les jours ! Et ce n'est pas en pratiquant une fois de temps en temps qu'on acquiert l'habilité nécessaire. Au final, les plus courageux qui ont essayé plusieurs fois finissent par laisser tomber...

Dommage. D'autant que les expressions régulières sont parfaitement intégrées aux frameworks modernes comme .NET, et que leur bonne utilisation permet des choses quasi magiques en une ou deux lignes d'intruction : tester la conformité d'une donnée complexe et même, ce que beaucoup ignorent, découper une données en groupes ou extraire une information dans un flot (par exemple repérer automatiquement les adresses web dans tout un texte).

Mais j'ai une solution pour vous !

J'ai trouvé un soft, gratuit, qui permet de saisir des expressions régulières, de les tester, et de les analyser (pour le debug c'est parfait, mais aussi pour.. apprendre!). Ce soft est vraiment bien fait et vaut le coup d'oeil dans tous les cas.

Je vous conseille donc de le télécharger et de le tester, vous pourrez insérer des expressions régulières complexes dans votre code et passer pour un héro à la machine à café, c'est pas cool ça ?

Ca s'appelle "Expresso" et ça se trouve là http://www.ultrapico.com/Expresso.htm.

Multithreading simplifié

Le multithreading c'est l'épouvantail du développeur. Vous en parlez, hop! tout le monde s'en va de la machine à café... et s'il y en a un qui ne part pas , c'est le genre fanatique qui va débaler une science opaque sur les AppDomains, les mutex et autres mots qui fâchent, du coup, c'est vous qui partez :-)

Je carricature à peine...

C'est tout le problème du multithreading. Pratiqué avec simplicité c'est une technique de plus en plus indispensable pour tirer partie des microprocesseurs multicoeurs et fluidifier les interfaces, mais voilà, comment faire simple avec une telle technique ?

Les puristes vous diront qu'il faut absolument comprendre la technique, et qu'en suite c'est facile... Un peu comme Coluche qui expliquait dans l'un de ses sketchs que son professeur de violon lui avait dit d'apprendre à jouer avec des gants de boxe parce que quand on les enlève ça semble facile...

Je ne vais pas vous dire qu'une démarche rigoureuse est inutile, j'ai un module de multithreading avancé dans mes plans de cours et, bien entendu, voir les choses en profondeur au sein d'une formation est le seul moyen de maîtriser cette technique. Mais il existe aussi des façons simples d'introduire un peu de multitâche dans vos applications.

Il s'agit du composant BackgroundWorker des Windows Forms. Certes le sujet tranche avec mes billets généralement plus orientés vers les super nouveautés hypra fraîches à tel point qu'elles sont même parfois en bêta... Mais il faut bien maintenir les applications existantes, les améliorer, et pour cela il existe, comme le BackgroundWorker des solutions pratiques qui ne nécessitent pas d'installer le framework 3.5 puisque cette classe a été fournie avec .NET 2.0.

De plus, ce composant Windows Forms n'impose pas de connaître les mécanismes du multithreading, il suffit de programmer ces événements comme un bouton. Trop facile ? Peut-être que cela choquera les puristes parce que "cela cache la réalité de ce qui se passe vraiment dans la machine", je leur répondrais que faire du C# au lieu de faire de l'assembleur c'est un peu pareil... Là où je les rejoindrais c'est que, bien entendu, la classe backgroundWorker ne doit pas être utilisée à tord et à travers. Si l'on désire concevoir des classes gérant finement le multitâche, il faut réellement comprendre et donc apprendre. Mais dans de nombreux cas, le BackgroundWorker pourra vous être utile et rendre plus fluide vos applications Windows Forms sans avoir à entrer dans les détails d'une technique un peu aride.

Mais trève de mots, le plus simple c'est de jouer avec ce composant pour se rendre compte de son utilité. Pour facilité la.. tâche... je vous ai préparé un petit projet VS 2005 qui montre comment se servir de backgroundWorker : BGW.zip (41,83 kb)

Un peu de douceur multitâche dans ce monde de multicoeurs...

Présentation des différentes facettes de LINQ (article à télécharger)

Le voilà enfin ! [Updated ! Version 1.1 en ligne]

un PDF de 32 36 pages et 5 6 projets exemples sous VS 2008 pour vous présenter les différentes facettes de LINQ. Je n'en voyais plus le bout de cet article ! Non par lassitude, bien au contraire, mais parce que LINQ est d'une incroyable richesse et que je voulais vous en dire la maximum.

Sans entrer dans les détails trop techniques de la syntaxe (la doc Microsoft est très complète et n'a nul besoin d'une redite), cet article présente le pourquoi et le comment de LINQ au travers d'explications et d'exemples de code.

  • LINQ to Objects
  • LINQ to SQL
  • LINQ to Dataset
  • LINQ to XML
  • LINQ to Entities

Sans prétendre que toutes ces versions de LINQ n'auront plus de secret pour vous après avoir lu l'article, vous en saurez certainement plus pour mieux comprendre pourquoi il y a eu un avant LINQ et qu'il va y avoir un après LINQ...

Pour télécharger l'article cliquez ici !

Avant de lire cet article il est préférable de connaître les nouveautés syntaxiques de C# 3.0, si ce n'est pas votre cas vous pouvez télécharger mon précédent article.

Pour la liste de tous mes billets sur LINQ cliquez ici.

Note de la version 1.1 : table des matières ajoutée + plus de détails sur Linq to Entities et un projet utilisant la bêta 3.

LINQ à toutes les sauces !

Je suis en train de boucler mon article de présentation de LINQ. Au départ je pensais m'en sortir en une dizaine de pages, mais j'en suis à plus du double... juste pour faire le tour des principales possibilités et sans détailler la syntaxe (ce n'est pas le but de cet article).

J'ai eu maintes fois l'occasion de vous dire ici que LINQ est l'innovation la plus fantastique que j'ai vue depuis longtemps dans un langage. Vous en saurez plus en lisant le prochain article qui sera en ligne ce week-end, mais pour vous prouver que LINQ peut servir partout et tout le temps voici deux exemples à contre-courant de l'idée qu'on se fait des utilisations possibles de LINQ :

Cas 1 : Lister les services actifs de Windows.

C'est bête mais balayer et filtrer une simple liste comme celle là (et de bien d'autres du même genre retournées par le framework .NET ou par vos applications), c'est produire du code pas très marrant... Avec LINQ ça devient :

using System.ServiceProcess; 
var srv = from s in ServiceController.GetServices()
         where s.Status == ServiceControllerStatus.Running
         select s.DisplayName;
ListBox1.DataSource = srv.ToList();

 
Je trouve ça élégant, pas vous ?

Cas 2 : Remettre à unchecked tous les Checkbox d'une form

Balayer certains contrôles d'une fiche n'est là non plus pas l'endroit où l'on s'attend à trouver du LINQ... Et pourtant ! Imaginons une fiche de saisie avec des tas de checkbox et un bouton "raz" de remise à zéro de la fiche. Balayer tous les contrôles de la fiche pour ne sélectionner que les checkbox n'est pas un code bien complexe mais avec LINQ ça devient tellement plus chouette !

var cb = (from Control c in this.Controls select c).OfType<CheckBox>();
foreach (var c in cb) c.Checked=false;
 

C'est pas plus joli et plus clair écrit comme ça ? (et encore on pourrait se passer de la variable "cb" et intégrer directement la requête LINQ après le "in" du "foreach")?

Bref, LINQ j'adore. Et j'espère bien que le papier à venir va vous transformez en fans vous aussi ! alors... Stay tuned !

Les nouveautés syntaxiques de C# 3.0

Les expressions Lambda vous connaissez ?

Et l'inférence des types locaux, les méthodes d'extension, les expressions d'initialisation des objets ou les types anonymes ?

Si tout cela sonne bizarrement à vos oreilles, n'hésitez plus une seconde : téléchargez le nouvel article que j'ai mis en ligne gratuitement !

Voici le lien, il n'y a qu'à cliquer ici !

Vous êtes encore là ?

... Alors ne loupez pas le tout dernier article "Présentation de LINQ avec C#", un papier de 32 pages riche en exemples !

SQL Server 2008 et le type FileStream - résumé de la conférence DAT304 des TechEd 2007

Gérer des données "raw" tels que des fichiers multimédia, de la documation, etc, dans une base de données est un sujet qui divise les développeurs depuis longtemps. SQL Server 2008 va (enfin) mettre fin à cette dispute de principe !

DAT304 - Managing Unstructured Data in SQL Server 2008: Introducing the Filestream Datatype

Je n'ai suivi que partiellement cette conférence, il faudra d'ailleurs que je profite de la diffusion en ligne des vidéos pour les participants aux TechEd pour la regarder en totalité. Ce qui m'intéressait c'était l'info elle-même qui se résume à un nouveau type champ dans SQL Server. Mais c'est une avancée de taille, je vais vous expliquer pourquoi en quelques lignes...

Le duel blob vs file system pour les données raw

En effet, il y a d'une côté les tenants du "tout file system" c'est à dire le stockage des fichiers en dehors de la base de données avec juste le stockage des noms de fichiers dans la base elle-même. Pour: la simplicité, la gestion des flux du file sytem généralement plus performante que les blobs. Contre: le manque cruel de consistence, pas de contexte transactionnel, backups à faire séparément, etc, etc. Je fais partie des "anti" d'ailleurs.

De l'autre côté il y a ceux qui préfèrent le stockage en blob. Pour : consistence des données, contexte transactionnel, backup unique, etc. Je pour pour cette solution en général. Contre : les blobs sont moins rapide en lecture / écriture de flux que le file system, certains SGBD imposent des limites à la taille des blobs. Si on fait abstraction de ce dernier argument (il suffit d'utiliser une base n'ayant pas cette limite, par exemple SQL Server 2005 ou même Firebird/Interbase), le léger inconvénient de la rapidité (qui reste modeste et peu gênant dans la plupart des cas) est largement, à mon avis et par expérience, compensé par les avantages de cette technique. Reste qu'on peut faire mieux...

Mélanger le meilleur des deux solutions 

C'est justement ce que propose SQL Server 2008 avec le nouveau type FileStream qui est une extension de VARBINARY(MAX) qui s'en distingue par un attribut lors de la création du champ.

Le principe est simple : on marie le meilleur des deux solutions existantes. On prend la souplesse (gestion des quotas par ex) et la rapidité du file system (NTFS obligatoirement) et on l'associe à la cohérence des données de la solution blob. En gros, SQL Server 2008 stocke les fichiers dans le file system mais assure l'accès à ces fichiers comme à n'importe quel autre champ ce qui permet la gestion transactionnelle, le backup unique et centralisé.

Conclusion 

Une solution simple et performante à un problème de plus en plus crucial, les utilisateurs devant de plus en plus gérer des données lourdes (photos, documents digitalisés, vidéos...) en synchronisme parfait avec les bases de données. Une fichier client peut comporter une photo, une fiche article une vidéo de présentation, tout cela n'est plus "exotique", cela devient une contrainte légitime d'exploitation.

Pour l'instant SQL Server 2008 est en bêta, mais comme son nom l'indique il devrait être bientôt sur le marché...

Encore une bonne idée, ingénieuse et simple à mettre en oeuvre. Je trouve que les équipes de dev de MS ont vraiment l'âme créative depuis qu'on est entré dans ce que j'appelle "l'ére .NET". Souhaitons que ça dure le plus longtemps possible !

A+ pour un nouveau billet. Stay tuned !