Génération de code client
Lorsque vous liez un projet Silverlight et un projet de couche intermédiaire à l'aide des Services RIA WCF, les Services RIA génèrent des classes de proxy client pour l'application cliente, basées sur des entités et des opérations que vous avez exposées dans la couche intermédiaire. Étant donné que les Services RIA génèrent ces classes, vous n'avez pas besoin de dupliquer une logique d'application de la couche intermédiaire sur la couche de présentation. Toutes les modifications que vous apportez au code de la couche intermédiaire sont synchronisées avec le code de la couche de présentation lorsque vous régénérez le projet client. Lorsque vous ajoutez un lien des Services RIA à une solution, une dépendance de génération explicite est ajoutée à la solution, qui force le projet serveur à se générer avant de générer le code du projet client.
Le code généré se trouve dans un dossier nommé Generated_Code dans le projet client. Pour voir ce dossier, vous devez sélectionner Afficher tous les fichiers dans la fenêtre Explorateur de solutions du projet client. Vous ne devez pas modifier directement les classes dans le dossier Generated_Code parce qu'elles seront remplacées lorsque le projet client sera régénéré. Cependant, vous pouvez ouvrir le fichier généré pour consulter le code disponible pour le projet client.
.png "RIA_GeneratedCode")
L'algorithme qui génère le code client suit ces règles de base :
Analyser tous les assemblys générés ou référencés par le projet de couche intermédiaire pour les classes DomainService, les classes d'entité ou le code partagé.
Pour chaque service de domaine annoté avec l'attribut EnableClientAccessAttribute, générer une classe qui dérive de la classe DomainContext.
Pour chaque méthode de requête, méthode de mise à jour personnalisée (méthode de mise à jour dont la propriété UsingCustomMethod a la valeur true), ou opération d'appel dans la classe DomainService, générer une méthode dans la classe de contexte de domaine.
Pour chaque classe d'entité exposée par un service de domaine, générer une classe proxy d'entité. Une classe d'entité est exposée quand elle est retournée par une méthode de requête.
Copier le code balisé pour le partage sur le projet client.
L'image suivante montre le code client généré pour un projet de couche intermédiaire.
.png "Génération de code client")
DomainService et DomainContext
Une classe dérivant de DomainContext est générée pour chaque classe DomainService selon les règles suivantes :
La classe de contexte de domaine est générée avec le même espace de noms que le service de domaine.
La classe de contexte de domaine contient trois constructeurs :
un constructeur par défaut qui incorpore l'URI nécessaire pour communiquer avec le service de domaine sur http à l'aide d'une classe WebDomainClient ;
un constructeur qui autorise le client à spécifier un URI alternatif ;
un constructeur qui autorise le client à fournir une implémentation personnalisée de DomainClient (utilisée généralement pour effectuer un test unitaire ou une redirection vers une couche de transport personnalisée).
Pour chaque méthode de requête dans la classe DomainService, générez une méthode EntityQuery qui peut être utilisée dans le projet client pour charger des entités.
Pour chaque opération d'appel, générez une méthode InvokeOperation correspondante qui peut être utilisée pour appeler cette opération de façon asynchrone.
Pour chaque méthode marquée avec l'attribut Update(UsingCustomMethod=true), générez des méthodes pour l'appeler et déterminer si elle a été appelée.
Des méthodes publiques du service de domaine, effectuant les insertions, les mises à jour ou les suppressions, sont à l'origine du fait que l'objet EntityContainer généré dans le contexte de domaine est généré avec un indicateur EntitySetOperations qui précise quelles opérations sont autorisées sur le client.
Classe d'entité et classe proxy d'entité
Les règles suivantes sont appliquées lors de la génération de la classe proxy d'entité :
La classe proxy est générée avec les mêmes nom et espace de noms que la classe d'entité dans la couche intermédiaire.
Le type d'entité racine dérive de la classe d'entité. Les types d'entité dérivés dérivent des types de base correspondants exposés par la couche intermédiaire.
Chaque propriété publique qui contient un type pris en charge et n'est pas marquée avec l'attribut ExcludeAttribute dans la classe d'entité est générée dans la classe proxy, sauf si cette propriété existe déjà dans le projet client. Pour plus d'informations, consultez la section « Éviter des membres en double » plus loin dans cette rubrique. Object n'est pas un type pris en charge.
Les accesseurs Set de chaque propriété contiendront un code qui effectue la validation et notifie les clients que la propriété est en cours de modification et a été modifiée.
Les attributs de métadonnées sont combinés avec la classe d'entité dans le code généré. Aucune classe de métadonnées n'existera sur le client.
Si possible, les attributs personnalisés sont propagés à la classe proxy. Pour une description des conditions nécessaires pour que l'attribut personnalisé existe dans le projet client, consultez la section suivante « Attributs personnalisés ».
Un seul attribut CustomValidationAttribute est propagé au membre si un type et une méthode de validation identiques sont spécifiées dans plusieurs instances de CustomValidationAttribute pour ce membre.
Attributs personnalisés
Les attributs personnalisés sont propagés à la classe proxy si leur ajout ne provoque pas d'erreur de compilation dans le projet client. L'attribut personnalisé sera propagé dans les conditions suivantes :
Le type de l'attribut personnalisé doit être disponible sur le projet client.
Les types spécifiés dans la déclaration d'attribut personnalisé doivent être disponibles sur le projet client.
Le type d'attribut personnalisé doit exposer des accesseurs Set publics pour toutes ses propriétés, ou exposer un constructeur autorisant la définition de propriétés sans accesseurs Set publics.
Si un attribut personnalisé requis n'est pas propagé au client, vous devrez peut-être ajouter une référence d'assembly dans le projet client. Ajoutez une référence à tout assembly nécessaire pour que l'attribut personnalisé soit compilé dans le projet client. Vous pouvez aussi partager un attribut personnalisé entre les couches en le définissant dans un fichier partagé.
Code partagé
Quand vous partagez des fichiers de code entre la couche intermédiaire et la couche de présentation, le code est copié sans aucune modification sur le projet client. Vous spécifiez un fichier de partage en le nommant selon le modèle *.shared.cs ou *.shared.vb. La structure du répertoire du projet de couche intermédiaire qui contient les fichiers partagés est reproduite dans le dossier Generated_Code.
Lorsque vous ajoutez un type personnalisé dans un fichier de code partagé, puis retournez ce type à partir d'une opération d'appel, la méthode générée dans le contexte de domaine ne retournera pas le type personnalisé. La méthode dans le contexte de domaine retournera un type qui fait partie de l'infrastructure. Par exemple, si vous créez un type personnalisé nommé MyCustomDictionary qui implémente IDictionary et que vous spécifiez ce type comme valeur de retour pour une opération de domaine, la méthode générée dans le contexte de domaine ne retournera pas MyCustomDictionary. Au lieu de cela, elle retournera un objet Dictionary.
Pour plus d'informations, consultez Code partagé.
Éviter des membres en double
Lors de la génération d'une classe proxy d'entité, il est possible qu'un type et un membre identiques aient déjà été définis dans le projet client à l'aide des types partiels. Vous avez dû définir le membre dans le code partagé ou dans un code qui existe uniquement dans le projet client. Les Services RIA vérifient les membres existants avant de générer la classe proxy. Tout membre déjà défini ne sera pas généré dans la classe proxy.