Hier je vous ai résumé la conférence DAT201 qui présentait l'Entity Framework. Aujourd'hui je vous parlerai plus brièvement d'une autre conférence. Cette brièveté du résumé ne doit pas vous induire en erreur : la conférence DAT303 de Pablo Castro, Technical Lead, est peut-être la meilleure à laquelle j'ai assitée.
D'abord Pablo est un jeune gars sympa. Ensuite malgré un fort accent cubain ou mexicain il a soutenu une conf à un rythme d'enfer tout en étant d'une grande clareté, une vraie conf technique comme je les aime, faite par un passionné qui connaît son affaire. Enfin, cette conférence dépassait le cadre de la présentation générale pour parler vrai et pratique. Là, Pablo m'a appris des choses sur l'Entity Framework. Des trucs pas simples à découvrir tout seul, une conférence qui fait vraiment gagner du temps et de la compétence. Merci Pablo !
Si le résumé sera court c'est que 95% de la conférence de Pablo était basée sur du code. Vous imaginez bien qu'il n'était pas possible de prendre le tout en sténo dans la pénombre de la salle de conf... J'ai revisionné aujourd'hui la conf (puisque toutes les sessions principales ont été filmées), et franchement même assis dans mon bureau à l'aise il nétait pas possible de noter la totalité des manips, toutes essentielles. J'ai d'ailleurs demandé à Pablo s'il pouvait avoir la gentillesse de m'envoyer le code source de ces démos, et s'il accèpte je les mettrais en téléchargement ici.
Donc de quoi s'agissait-il ?
Bien entendu de l'Entity Framework, depuis mon billet d'hier vous devez savoir de quoi il s'agit (sinon foncez lire ce dernier, ne vous inquiétez je ne bouge pas, vous pourrez revenir ici plus tard :-) ).
Mais il n'était plus question ici de parler en général ou même en détail du fonctionnement de EF, il s'agissait de voir comment s'en servir "en vrai" dans trois conditions :
En effet, le principal problème de toute surcouche est de manger un peu plus de CPU et de mémoire que la couche du dessous. C'est la règle en informatique, plus c'est pratique et puissant, plus la machine doit pédaler. Et même si EF est très efficace et très optimisé, ce qu'il fait en plus possède forcément un coût. Il est donc essentiel de pouvoir maîtriser ce coût en faisant des économies là où cela est possible.
La bonne nouvelle c'est que EF le prévoit et que la mise en oeuvre est simple. La moins bonne nouvelle c'est que la chose devient un poil plus "mystique" et qu'il faut réfléchir un peu plus. Mais un informaticien paresseux des neurones est soit en chômeur en puissance, soit un ex-informaticien au RMI...
Change tracking et Identity resolution
Deux mécanismes peuvent être économisés (et les ressources CPU/RAM qui vont avec) : Le change tracking et l'identity resolution. Le premier, détection des changements, permet à l'EF de savoir quels objets ont été modifiés pour savoir comment appliquer les mises à jour à la base de données. Si certaines entités (ou grappes d'entités) ne seront pas modifiées on peut alors se passer du mécanisme de détection des changements... L'identity resolution, ou résolution des identités est utilisée pour identifier de façon formelle toutes les instances des entités. Il est en effet primordial pour le système de savoir à quel(s) enregistrement(s) de la base de données corespond(ent) l(es) entité(s) sinon il est impossible d'envisager des fonctions comme le refresh, l'update ou le delete...
Heureusement EF est très bien conçu et il est possible de stopper ces mécanismes là où on le désire. Ce court billet (qui devient déjà long...) n'entrera pas dans les détails, je prépare un article sur la question, format plus adapté à un long exposé technique avec exemples de code.
Des entités qui passent les frontières...
Un autre problème se pose, notamment dans les applications en multi-tiers : lorsqu'une instance d'entité est passée en dehors du système, EF en perd la trace... Imaginons un serveur applicatif qui utilise EF pour accéder à une base de données afin d'offrir des services de type WCF (ex remoting, pour simplifier) ou même des services Web. Les changements dans les objets ont lieu en dehors même de la machine qui utilise EF. Le lien est cassé et si l'objet revient au serveur applicatif qui doit en retour mettre à jour la base de données, EF ne le connaîtra plus et ne pourra pas l'intégrer à son mécanisme de mise à jour de la base.
Là encore EF permet de contourner le problème. La façon de le faire sera aussi décrite dans le papier en cours de préparation, soyez patients !
Compilation LINQ
Enfin, Pablo a montré comment économiser des ressources du côté de LINQ cette fois-ci en utilisant la possibilité de compiler la requête sous la forme d'un delegate qu'il suffit ensuite d'appeler. L'utilisation des expressions Lambda et l'utilisation des interfaces idoines permettent même d'avoir une requête compilée mais paramétrique dont le résultat peut être réutilisé dans une autre requête LINQ. Pas de magie, et peu de code à taper pour réaliser tout cela. En revanche, une fois encore, cela ne s'improvise pas si on ne connaît pas l'astuce.
Conclusion
Une conférence riche, dense et instructive. Je pourrais en parler encore des pages entières mais sans la contrepartie du code exemple et des explications qui vont avec ce billet deviendrait vite ennuyeux. Je préfère m'arrêter là et réserver les détails d'implémentation pour l'article que je prépare sur ce sujet. Bien entendu il sera annoncé ici et sera téléchargeable gratuitement comme d'habitude.
Une dernière chose, Pablo nous a fait voir un peu Astoria, un procédé permettant d'exposer une (partie d'une) base de données en HTTP dans un formalisme XML. Une sorte de Web service généré automatiquement pour chaque classe et qui, par des GET ou des POST permet d'accéder aux données mais aussi de mettre à jour les données dans un mécanisme de type accès à une page Web ! Je n'ai pas eu le temps de creuser la question ni de faire tourner de bêta de Astoria, mais soyez sûrs que dès que j'en aurais fini avec mon tri de toutes les conférences des TechEd, Astoria sera au programme !
Plein de nouveautés encore à venir, so, stay tuned !