ADO .NET Data Services : un “vrai” contexte côté client
Une des forces d’Entity Framework est l’éco-système qui gravite autour. Même si ADO .NET Data Services peut être utilisé sans EF, j’incluerais tout de même cette technologie dans l’éco-système. En effet, si vous utilisez EF avec ADO.NET Data Services, vous n’avez presque plus rien à faire pour utiliser des requêtes LINQ côté client ainsi que pour persister les modifications.
Cependant, le proxy généré côté client a plusieurs défauts :
- Prenons Northwind, si on ajoute un orderDetail à un order (order.OrderDetails), la propriété orderDetail.Order reste null. De même, si on affecte un order à l’orderDetails (orderDetail.Order), la collection d’orderDetail de l’order n’est pas modifée.
- Si on charge les orders et ensuite les orderDetails, les collections OrderDetails des orders sont vides et la propriété Order des orderDetails est null. Pourtant, OrderID fait partie de la clé des orderDetails, donc on devrait avoir automatiquement la relation (comme le fait le contexte EF).
//Pour avoir la relation avec ADO.NET Data Services, il faut utiliser la méthode Expand dans la requête ou utiliser la méthode LoadProperty à postériori.
Avec EF4, on peut intégrer dans le modèle toutes les FK (avec la V1, seules celles étant incluses dans la PK l’étaient). Ceci est une super nouvelle dans notre cas car ça signifie qu’en théorie, il est possible de regénérer automatiquement les relations. - Pour ajouter un order avec des (nouveaux) orderDetails, vous devez faire un Add sur l’order, puis sur tous les orderDetails (le contexte MS ignore les relations). Ensuite il faut encore appeler les méthodes SetLink et AddLink (parce que la clé de la table Orders est un Identity). Il faut donc écrire le code suivant:
context.AddToOrders(o);
foreach (var od in o.OrderDetails)
{
context.AddToOrderDetails(od);
context.AddLink(o, "OrderDetails", od);
context.SetLink(od, "Order", o);
}
- Le contexte MS ne gère pas non plus tout seul le tracking des modifications. Il faut manuellement appeler la méthode UpdateObject pour passer une entité dans l’état Modified.
- Dans le cas d’un nouvel order, si on ajoute un orderDetail au contexte et qu’on ajoute seulement après l'order associé, on va avoir une exception lors du SaveChanges car le contexte ne modifie pas l’order des Add
Mon idée était de résoudre tous ces problèmes en codant un nouveau contexte ADO.NET Data Services basé sur le contexte MS. Bien sûr, je voulais une solution totalement générique (ie indépendante du modèle). Pour faire cela, J’ai utilisé un template T4 qui utilise les informations de l’edmx. Cela implique deux contraintes:
- Vous devez utiliser EF côté serveur
- Lorsque vous développez votre client, vous devez avoir accès à l’edmx (côté serveur)
Mon template résoud tous les problèmes énoncés précédemment. Mission remplie ! 
Vous pouvez le télécharger ici.
Vous pouvez ausi télécharger toute la solution (avec les tests unitaires) ici et le script de création de la base là.
//J’admet que quelques parties du code sont assez “crades” mais ADO.NET Data Services est une techno extrêmement “fermée” et cela m’a parfois empêché de respecter les règles de l’art. J’aurais peut-être aussi eu de meilleures idées si je n’avais pas codé aussi tard la nuit 
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
