Stéphanie Hertrich (relations Microsoft développeurs) et Sébastien Pertus – ou “Petrus”? 🙂 – présentent une session autour d’un besoin métier multi-device, réversible (déployable dans le cloud ou à demeure), et à authentification déportée. Il s’agit d’une application de gestion de caves à vins qui leur sert de fil rouge pour toute l’après-midi, entre la gestion de l’architectures, des services, du client mobile et de tout ce qui va autour. Les orateurs ont tout deux un blog sur lequel ils partagent la façon dont on peut créer cette application pas à pas. Ca vaut le coup d’aller voir ça, je pense que vous devriez retrouver rapidement le lien avec leur nom, le mot clé blog et si ça ne suffit pas, en rajoutant “Cave a vins”.
Mapping ORM avec EntityFramework
Les versions 4.2 et 4.3 se basent sur la version EF4 qui est livrée avec le Framework 4.0, et rajoutent une librairie EntityFramework avec les nouveautés (certainement par méthodes d’extension, etc.). Par contre, la version 4.5 aura besoin des innovations présentes dans le framework 4.5, et on ne pourra plus évoluer de manière aussi transparente, même si l’effort restera très limité.
Une classe hérite de DbContext et contient des DbSet<type à inclure>. Ensuite, on va instancier cette classe, rajouter des données et faire un SaveChanges. Cela suffit pour générer la base de données, avec pour convention d’utiliser le namespace et le nom de la classe de contexte. On aurait aussi pu utiliser un constructeur base(connectionString) depuis notre constructeur de classe de contexte. Il s’agit bien là d’un approche de type code-first, puisque même la mise en place de la base de données est subordonnée à l’exécution du programme.
On peut ajouter [System.ComponentModel.DataAnnotations.StringLength] pour enrichir les propriétés sur lesquelles on travaille. On a également la possibilité de dire qu’une propriété n’est pas mappée, qu’elle est obligatoire, etc. Ne pas oublier de marquer les accesseurs de liste en virtual, par contre, sinon le Lazy Loading ne pourra pas fonctionner.
Il est également possible de laisser les objets POCO complètement inchangés. Pour cela, on utilise l’API Fluent qui donne accès à un DbModelBuilder, sur lequel on pourrait ajouter ces contraintes sans toucher aux classes, propriétés, etc.
On peut surcharger le SaveChanges et utiliser le ChangeTracker pour ajouter des comportements métiers à la sauvegarde. Si on utilise du Linq normal, on voit dans SQLServer Profiler passer deux fois la requête. Par contre, si on utilise la fonction Find(), il y a bien utilisation du cache, dans le scope du DbContext bien sûr.
Gestion de la migration
Lors des mises à jour, on peut avoir des policies de destruction de bases de données en automatique. Evidemment, ce n’est pas possible d’utiliser ce mode destructif de données en production. La version 4.3 amène un modèle de migration de base de données, qui permet enfin d’avoir une gestion de la mise à jour des bases de données sur les changements de code. Ceci se fait avec du PowerShell ou bien sûr en code .NET.
install-package EntityFramework –includePreRelease dans NuGet permet de prendre la version 4.3 ainsi que tout ce qui est nécessaire en termes de dépendances pour qu’elle fonctionne. Bien sûr, quand il s’agira de la release officielle, il ne sera plus utile de rajouter l’option includePreRelease. Il faut inclure une classe de migration qui hérite de DbMigrationsConfiguration. On a toutefois le choix de dire que pour chaque marque de modification, on laisse faire EF 4.3 pour la mise à jour. Update-Database –Verbose –Force permet de prendre une photo de la structure de base de données, ou bien de lancer la migration automatique.
Nouveautés EF 4.5
Support des énumérations, des données géospatiales, des améliorations de Linq (en particulier la compilation automatique), etc. Par contre, tout ça n’arrivera que dans le Framework 4.5.
Publication des données
OData est une convention / une spécification plus qu’un protocole. Le principe est avant tout de pouvoir requêter sans connaître à l’avance la structuration des données.
Une instruction que je ne connaissais pas en OData : $expand. Il faudra que je voie à quoi ça sert… WCF Data Services permet de prendre n’importe quelle IQueryable et de l’exposer sous forme de flux OData. Enfin, OData V3 (seulement avec la CTP Octobre 2011 de WCF Data Services) supportera les types de données géolocalisés.
[QueryInterceptors(“Table”)] permet de rajouter la logique de droits pour les accès sur une table donnée. On peut alors se servir de l’authentification IIS, mais aussi de Access Control Services qui est plus large. ACS permet de déporter l’authentification à un processus externe, comme LiveID, Facebook, YahooID, etc. En ACS, du côté client, on surcharge le SendingRequest de WP qui va rajouter un token OAuth. Les QueryInterceptors permettent de renvoyer une expression qui permet de dire sur une ligne de donnée particulière (vue comme une instance d’un type) est autorisée ou pas.
Au final, beaucoup de choses apprises dans cette très bonne session technique, mais il va vraiment falloir tester tout ça en profondeur pour mieux comprendre et être capable de pratiquer.
