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

Exemple : nous désirons supprimer des objets en cascade (suppression d’une commande, qui implique la suppression des lignes de commandes, qui implique …).

Cette suppression sera plus rapide si son exécution est confiée au moteur de base de données, plutôt que par des appels multiples sur un contexte EF.

D’où la création d’une procédure stoquée, et son intégration au sein d’EF.

Lorsque l’on désire exploiter les procédures stoquées au sein d’EF, il suffit de passer par une "Function Imports" mappée sur la procédure référencée au préalable dans EF.

Si cette dernière un objet déjà exploité par EF, aucun problème : la méthode liée à la procédure est dynamiquement générée dans le contexte EF lors de la création de la fonction EF.
Par contre, lorsqu’il s’agit de retourner un type simple ou void : la méthode n’est pas générée…

Dans ce cas de figure, il faut donc "mettre les mains dans le moteur".

Pour ce faire, voici les étapes :

1. Créez votre procédure stoquée (qui ne retourne rien…),
   
2. Dans Visual Studio, ouvrez l’edmx, et sur le schéma, cliquez droit (menu contextuel), sélectionnez "Update Model From database" (voir ci dessous)
   
   

3. Dans l’écran de synchronisation du modèle Entity Framework, déployez Stored Procedure et sélectionnez celle à "injecter" comme fonction dans Entity Framework, et validez…
   
   

4. Ouvrez le Model Browser, et dans la partie qui concerne la description de la base de données utilisée par EF, déployez Store Procedure. Click droit sur celle qui nous intéresse et sélectionnez "Create Function Import"
   
    
   (ce qui est grisé est le nom du datamodel du projet)

5. Cela entraine l’ouverture de l’écran de paramétrage de la fonction.
   Ecran dans lequel, nous pouvons ajouter des précisions concernant la fonction (donc son nom).

    

   Passé ce stade ci, si le type de retour avait été Entity (un objet géré par EF), il aurait généré le code permettant l’appel de la fonction.

   Pour vérifier qu’il a bien enregistré la fonction : ouvrez le Model Browser, et déployer la partie entity jusqu’aux fonctions :

    

6. Créez une classe partielle portant le même nom, et même namespace que le contexte entity de votre modèle de données.

   PS : Pour connaitre le nom de la classe :

   • ouvrez l’edmx
   • cliquez sur l’arrière plan
   • F4 pour ouvrir l’écran de propriétés
   • reprenez le nom de la propriété "Entity Container Name"
     
     

   Re-PS : Pour connaitre le chemin du namespace de la classe :
   
   Ouvrez le fichier .cs lié à l’edmx, et copiez le namespace en tête de fichier.

   Maintenant que vous disposez du nom complet de la classe (namespace + nom de classe), vous pouvez créer une classe qui va porter le même nom, même namespace, mais avec le mot clé partial. &#160; <br />

      1: namespace MonNamespaceEF  

      2: {    

      3:     using System;    

      4:     using System.Collections.Generic;    

      5:     using System.Linq;    

      6:     using System.Text;      

      7:  

      8:     public partial class MainDataModel    

      9:     {        

     10:     }  

     11: }  

7. Dernière étape : le code permettant d’exploiter EF par "l’intérieur".

   Avant de montrer le code, une petite explication.

   Entity Framework est une couche de type DAL (couche permettant les accès aux données + le mapping relationnel objet).
   
   Étant donné qu’EF est conçu pour pouvoir fonctionner sur plusieurs sources de données (SQL Server, ou autre), il offre à l’utilisateur ses propres implémentations de DbConnection, DbCommand, etc afin de garder cette indépendance.
   Donc, dans le code exposé ci dessous, nous n’utilisons ni d’OleDb, ni de SQLClient mais bien EntityConnection, EntityCommand, etc.

      1: namespace ClassLibrary1

      2: {

      3:     using System;

      4:     using System.Collections.Generic;

      5:     using System.Linq;

      6:     using System.Text;

      7:     using System.Data.EntityClient;

      8:  

      9:     public partial class MainDataModel

     10:     {

     11:         /// <summary> 

     12:         /// Supprime une machine en profondeur (impacte toutes les tables liées) 

     13:         /// </summary> 

     14:         /// <param name="idGamme">The id gamme.</param> 

     15:         public void DeleteMachineDeep(String codeMachine)

     16:         {

     17:             // Crée une connection à partir de la cnnStr du datacontext 

     18:             using (EntityConnection conn = new EntityConnection(this.Connection.ConnectionString))

     19:             {

     20:                 try

     21:                 {

     22:                     EntityCommand cmd = conn.CreateCommand(); // crée une EntityCommand 

     23:  

     24:                     // CommandText correspond au nom de la fonction d'import (au sens Entity) 

     25:                     // le format d'identification est 'ContainerName.Stored Proc Name'  

     26:                     cmd.CommandText = String.Format("{0}.{1}", this.DefaultContainerName, "SUPPR_MACHINE");

     27:  

     28:                     cmd.CommandType = System.Data.CommandType.StoredProcedure;

     29:                     cmd.Parameters.AddWithValue("codeMachine", codeMachine); // ajout du param 

     30:  

     31:                     conn.Open();

     32:  

     33:                     cmd.ExecuteNonQuery();

     34:                 }

     35:                 catch (Exception)

     36:                 {

     37:                     conn.Close();

     38:                     throw; // renvoi l'exception pour traitement, 

     39:                 }

     40:             }

     41:         }

     42:     }

     43: }

8. L’utilisation :

      1: ...    

      2: var dataCtx = new MainDataModel();    

      3: dataCtx.DeleteMachineDeep("ST1236");  

      4:  ...  

Avant de conclure, je souhaite revenir sur un point important : le fait qu’EF utilise des types d’objets de manipulation de source de données indépendant des implémentations réelle (EntityCommand, EntityConnection, etc) prouve qu’il a été conçu pour être exploité de façon indépendante du type de moteur de base de données sur lequel il s’appuie (et ce proprement).

@+