Astoria (relation 1..N)
Par Thierry Thoua,
jeudi, juin 5 2008.
Lien permanent
Astoria
Suite à la mise à jour de Visual Studio 2008 (le SP1 en bêta) disponible depuis quelques jours, il est désormais possible d'effectuer sous une même transaction une sauvegarde de plusieurs objets liés en relation 1 à N. En effet, dans la précédente version d'astoria, il y avait un bug ;-). Voici donc la procédure de mise en place... et les points à mettre en avant lors de la migration de l'ancienne solution.
- Voici la structure de ma base de données (simpliste ..)
- Projet Serveur -> Rien ne change
- Projet Client
- Ajout des reférences dans mon projet "client"
Ajouter une référence à l'assembly "client" de ADO.NET Data Services. Elle est disponible dans la GAC avec le nom "System.Data.Services.Client". Précédement, elle s'appelait "Microsoft.Data.WebClient".
- Génération des classes proxy
datasvcutil.exe /uri:http://urlDeploy/WebDataService.svc /out:ExempleEntities.cs
- Code qui crée une Bill + 2 BillItem et enregistre tout en 1 seule transaction
DataServiceContext data
= new DataServiceContext(new Uri(@"http://urlDeploy/WebDataService.svc/"));
Bill bill = new Bill { Name = "Nom" };
BillItem item1 = new BillItem { SubName = "Sub1" };
bill.BillItem.Add(item1);
BillItem item2 = new BillItem { SubName = "Sub2" };
bill.BillItem.Add(item2);
//Ajout des objets
data.AddToBill(bill);
data.AddToBillItem(item1);
data.AddToBillItem(item2);
// On crée un "lien" pour les ID de référence
data.AddLink(item2, "Bill", bill);
data.AddLink(item1, "Bill", bill);
// On enregistre en mode "batch" ... L'id de "Bill" généré par la DB ne sera
// positionné correctement sur les enfants qu'en mode "Batch"
data.SaveChanges(SaveChangesOptions.Batch);
6 réactions
1 De Steve Degosserie - 05/06/2008, 10:38
ça marche vraiment comme ça Astoria ? Quelle horreur ce code, on se croirait revenu 5 an en arrière. :o/
2 De Thierry Thoua - 05/06/2008, 20:57
Je nuancerais fortement ce propos Steve ;-). Je m'explique ... En effet, c'est tres lourd (trop) d'ajouter du code AddLink / AddToBillItem dans le code ... mais il ne faut pas oublier que astoria ... C'est du REST ... Après, il y quelque chose que j'apprécie beaucoup dans astoria => La possibilité d'écrire des requêtes LINQ qui seront converties en uri et traitées par le service web ... Cette partie la est top ... En effet, il n'y a aucune implémentation (classe webservice) à faire côté serveur ... Après pour le SAVE/UPDATE/DELETE ... Il reste beaucoup de taf pour avoir un produit fini top ... Mais Astoria n'est pas encore released ... Croisons les doigts ... Moi j'espère beaucoup de ce produit :)
3 De Steve Degosserie - 06/06/2008, 07:25
Linq te permet peut-être de faire de joli query, mais pour le reste, ce code est horrible. En gros, tu dis 3 fois 'ajoute 2 bill items à ma bill' ... espérons que cela soit fixé dans la release.
REST + Linq côté client, très bien mais g une bête question : combien de requêtes Http sont envoyées au serveur quand tu fais 'data.SaveChanges' ?
Le REST c'est bien beau, mais tu te vois implémenter ça dans une application Business ?
4 De Steve Degosserie - 06/06/2008, 09:48
Je reviens sur ma dernière question, à savoir le fait d'utiliser REST comme support de Data Access dans des applications RIA : en gros, je ne suis pas contre du tout, mais je pense qu'il faut attendre d'avoir un framework vraiment mature (peut-être Astoria, à voir) reposant sur des briques comme Linq et Entity Framework (qui n'est aussi qu'une première release soi dit en passant).
J'ai juste un peu peur que le développeur qui a déjà du mal à voir l'impact d'un ORM sur le requêtage SQL de la DB (1 requête Linq côté serveur -> 1 à N requêtes SQL), aura encore plus de mal à ne pas 'oublier' de minimiser le nombre d'appels réseau quand il fera du Linq dans sa jolie application Silverlight (1 requête Linq côté client -> 1 à N requêtes Astoria -> 1 à N requêtes SQL). Un petit calcul simpliste nous amène vite à une démultiplication du nombre de requêtes SQL de l'ordre de N² au lieu de N ...
Nul doute que Microsoft optimisera Astoria pour minimiser le nombre de 'data requêtes', mais bon, il y a toujours moyen de mal utiliser une technologie (cfr. Ajax).
Je vois une autre mauvaise pratique qu'Astoria risque de favoriser, à savoir, le fait d'influencer la structure de la DB en fonction de la manière dont les données sont présentées dans les écrans ... et oui, parce qu'en gros, ce qu'Astoria permet, c'est de faire du bon vieux 'Client / Serveur' over Http ... j'accèdre à une vue de ma DB directement à partir de mon RIA.
En conclusion de cette longue deuxième réponse, wait & see ;o) lol
5 De Thierry Thoua - 06/06/2008, 13:20
Je partage totalement ton avis. Tout comme Silverlight ... je pense qu'il faut attendre une version 2 du produit. Je reste sur mon premier commentaire ... Wait & See mais je vois beaucoup de possibilités dans ce produit ... Le tout est de voir comment il sera utilisé.
6 De Pierre-Emmanuel Dautreppe - 08/06/2008, 17:16
Effectivement une série de commentaires intéressants !
En fait, je pense que tout ces produits ont l'inconvénient de leur avantage. Ce que j'entends par là, c'est que ce type de produit nous permet d'aller plus vite en masquant tout une "complexité" qui est faite derrière (j'imagine une version avancé d'astoria ou tous ces enregistrements de "bill" n'existeraient plus).
Et évidemment, comme cette complexité est caché, on peut facilement oublier (voire ne pas connaître) ce qui se passe derrière. Et effectivement, on en arrive vite comme dit steve à avoir N² de requêtes qui partent sans s'en rendre compte.
Tiens ça me rappelle certains xxxDataSource (Sql, Object, Xml, ...) qui sont mal maitrisés et sur lesquels on va forces bind parce qu'ils ne sont pas fait sufffisamment tôt à notre goût, ...