WCF RIA Services nous permet de requêter, de façon quasi transparente, une source de données depuis une application cliente Silverlight (par exemple).

La syntaxe utilisée consiste à appeler Load de l’objet DomainContext instancié et de lui préciser quelle query utiliser.

Ce mécanisme suffit largement pour des filtrages basiques.

Lorsque l’on a à utiliser des filtrage plus complexes, RIA se trouve vite à bout de souffle.

Pour les exemples ci dessous, nous considérons que nous disposons du modèle de données suivant (Entity Framework par exemple) :
Une voiture contient 0-n roues,
Les roues ne sont pas retournées par défaut avec les voitures sur le client (via RIA).

Exemple de situation complexe :

   1: var monDomainCtx = new VehiculeDomainSrv();

   2: var query = monDomainCtx.GetVoitureQuery().Where(

   3:     voiture => voiture.Roues.Any(roue=>roue.IsAPlat));

   4:  

   5: monDomainCtx.Load<Voiture>(

   6:     query,

   7:     loadOp=>

   8:     {

   9:         ... // opération de chargement des voitures à pneu plat

  10:     },

  11:     false);

Nous tentons ici (côté client), de demander à RIA d’aller rechercher toutes les voiture qui ont (au moins) un pneu crevé (sous requête).

Dans ce cas de figure (présence d’une ou plusieurs sous requête), RIA va nous renvoyer une exception dont le message parlera d’une impossibilité d’utiliser Any (mais ce serait la même chose pour Count, First, etc).

La solution :

Dans le DomainServices (donc sur le serveur), nous allons implémenter une méthode décorée de l’attribut « System.Web.DomainServices.QueryAttribute ». Nous implémentons donc nos propres query !

Cette méthode retournera donc un objet IQueryable (au même titre que celles fournies par défaut : GetVoitureQuery() )

   1: [Query()]

   2: public IQueryable<Voiture> GetFiltreVoitures(Boolean roueCrevee)

   3: {

   4:     // création de la query de base retournéà partir du DataModel

   5:     var dataCtx = new GarageLocationDataModel();

   6:     

   7:     return dataCtx.Voiture.Where(voit => voit.Roue.Any(roue => roue.IsAPlat));

   8: }

Lors de l’exécution, nous utiliserons le code suivant (côté client)

   1: var dataCtx = new VehiculeDomainSrv();

   2:  

   3: dataCtx.Load<Vehicule>(

   4:     dataCtx.GetFiltreVoiture(true),

   5:     loadOp=>

   6:     {

   7:         // Corps de méthode pour récupérer les résultats

   8:         ...

   9:     },

  10:     false);

Le client ne fait que demander l’exécution de la query, cette dernière sera bien entendu exécutée (physiquement) sur le serveur.

Petite précision sur les méthodes Query :

Il faut noter une petite restriction concernant les paramètres des query : il n’est pas possible (à ce jour) de passer en paramètre un objet d’un type qui encapsule tous les critères de recherche (exemple : CritereVehicule).

En effet, les seuls types autorisés par RIA comme paramètre de query sont les classes qui héritent d’EntityObject et les types simples.

Nous sommes donc “forcés” de lier les couches fortement (pour le moment).

Et un petit tip pour tout ceux qui utilisent WCF RIA Services.

Récemment, j’ai été confronté à un petit souci de design de modèle de donnée, qui a engendré un bug auprès de RIA.

Soit le cas suivant :

Je dispose donc (en base de données) de 5 tables :

ModèlePièce identifié par

• IdModelePiece

Fournisseur identifié par

• IdFournisseur

Pièce
Une pièce correspond à un modèle fournit par un fournisseur.
L’identifiant de la pièce est composite :

• Id du fournisseur
• l’id du modèle.

Machine
Une machine correspond à un modèle d’outil (par exemple), qui est composé de pièces.
La machine est identifiée par :

• IdMachine

CompositionMachine
Cette table sert à lié les pièces aux machines.
Donc, l’identifiant est (en composition naturelle) composite et plus complexe (quoi que ) :

• Id de la pièce (composé de idFournisseur + IdModelePiece)
• Id de la machine (IdMachine)

Dans ce cas précis, RIA ne pourra mettre à jour les données de la table CompositionMachine !

La raison principale semble liée à la méthode GetIdentity() qui ne retourne pas correctement l’id d’une clé composite, elle même constituée d’une clé étrangère composite + un autre clé étrangère

Donc, si d’aventure vous utiliser RIA, la solution doit impérativement passer par :

Chaque table a son id propre (style guid ou entier auto incrémenté) + une contrainte d’unicité sur ce qui aurait pu être une clé primaire (en conception naturelle). Cela permet d’éviter les composites dans les clés étrangères.

Dans ce cas de figure, RIA n’est pas confronté à une clé primaire, constituée de clés étrangères, dont un élément au moins est composite.

Ce qui pose donc problème à RIA est bien le fait d’être confronté à une clé primaire constituée de clé étrangères dont une au moins qui est composite.

C’est tordu, mais fallait le savoir!

Espérons qu’en v4 cela soit corrigé !

Ajouté le 04/03/2010
Le message exacte de l’exception était :
Unable to cast object of type ‘System.Windows.Ria.Data.EntityKey`2[System.String,System.Int32]’ to type ‘System.Windows.Ria.Data.EntityKey`2[System.Int32,System.String]’. »

Autres liens parlant du problème :

http://forums.silverlight.net/forums/p/130384/291497.aspx
http://betaforums.silverlight.net/forums/t/117417.aspx
http://forums.silverlight.net/forums/t/115342.aspx