Code partagé

Les Services RIA WCF vous permettent d'écrire la logique d'application partagée entre la couche intermédiaire et la couche de présentation. Il fournissent donc des fonctionnalités identiques sur le serveur et sur le client. Le code peut être partagé soit avec des fichiers source, soit avec des assemblys.

Contrairement au processus de génération automatique du code décrit dans la rubrique Génération de code client, le code partagé n'est pas modifié lors de la compilation. Au contraire, le code est soit copié, soit partagé à l'identique entre les couches. Le code partagé vous permet de définir des éléments de logique ou des extensions de classe partielles pour vos entités. Celles-ci sont définies une seule fois sur le serveur, mais elles obtiennent également sur le client le code généré afin que la même logique soit disponible aux deux endroits.

Fichiers source partagés

Vous pouvez ajouter des fichiers source à la couche intermédiaire, puis les désigner explicitement pour qu'ils soient partagés avec la couche de présentation. Le partage de fichiers source entre les couches peut se faire de deux manières. La première approche consiste à nommer les fichiers source d'après une convention d'affectation des noms partagée : *.shared.cs (pour C#) ou *.shared.vb (pour Visual Basic). La deuxième approche consiste à utiliser la fonctionnalité de fichiers liés de Visual Studio 2010.

Convention d'affectation de noms partagée

Lorsque vous utilisez la convention d'affectation des noms partagée (*.shared.cs ou *.shared.vb) pour partager des fichiers, vous mettez en œuvre un modèle de « transmission de type push » pour le partage de fichiers de code source. Les fichiers partagés sont copiés activement depuis le projet de couche intermédiaire vers le projet client pendant la compilation. La convention d'affectation des noms partagée ne fonctionne pour le partage de fichiers que si un lien des Services RIA existe entre les projets serveur et client.

La convention d'affectation des noms partagée présente les avantages suivants :

Avantages de la convention d'affectation des noms partagés	Description
Prise en charge intégrée	Aucune action supplémentaire n'est requise de la part du développeur pour conserver la synchronisation des fichiers partagés.
Transparence	Le nom indique clairement que le fichier est prêt à être partagé.
Maintenance automatique	Lorsque de nouveaux fichiers partagés sont ajoutés, tous les projets clients liés à la couche intermédiaire sont automatiquement mis à jour lorsque la solution est compilée.
Résolution facile des problèmes	Le développeur peut placer des points d'arrêt dans la version serveur ou client du fichier.

La convention d'affectation des noms partagée présente aussi les inconvénients suivants :

Inconvénients de la convention d'affectation des noms partagés	Description
Nouveau concept	Le développeur doit connaître la convention d'affectation des noms partagée.
Les fichiers sont copiés	Les fichiers partagés sont copiés physiquement vers les projets clients, ce qui signifie qu'un développeur risque de modifier la version copiée par inadvertance et de perdre ces modifications lors de la compilation suivante.

Pour plus d'informations, consultez Procédure : Partager le code via les fichiers source.

Fichiers liés

Les fichiers liés sont une fonctionnalité existante de Visual Studio 2010 et ne constituent pas une exclusivité des Services RIA . Un lien des Services RIA entre projets peut exister, mais il n'est pas obligatoire pour utiliser des fichiers liés. Lorsque vous utilisez l'approche des fichiers liés, vous implémentez un modèle « d'extraction de données » pour le partage de fichiers de code source. Le projet client ne contient aucune copie du fichier. Il ne fait que référencer le fichier dans le projet serveur.

Vous pouvez aussi lier à la fois les projets serveur et client à un fichier d'un autre projet.

L'approche des fichiers liés présente les avantages suivants :

Avantages des fichiers liés	Description
Fonctionnalité Visual Studio existante	Le développeur n'a pas à apprendre de nouvelle convention.
Le fichier n'est pas copié	Il n'existe que dans le projet serveur. Le développeur ne risque donc pas de modifier une version copiée du client et de perdre ces modifications lors de la compilation suivante.

L'approche des fichiers liés présente aussi les inconvénients suivants :

Inconvénients des fichiers liés	Description
Exige une action explicite de l'utilisateur	Le développeur doit lier chaque fichier partagé.
Pas de maintenance automatique	Chaque projet client doit être mis à jour si des fichiers partagés sont ajoutés ou supprimés.
Manque de transparence	Le développeur doit examiner le fichier projet pour savoir quels sont les dossiers partagés.
Résolution des problèmes malaisée	Il n'est pas facile de déterminer la couche qui a déclenché un point d'arrêt.

Pour plus d'informations, consultez Procédure : Partager le code via les fichiers source.

Assemblys partagés

Au lieu de partager des fichiers source entre projets, vous pouvez compiler le code dans une bibliothèque de classes, puis partager cette bibliothèque via des références d'assembly. Vous pouvez utilisez les bibliothèques de classes Services RIA WCF pour vérifier que les assemblys sont compatibles, même s'ils sont utilisés avec des infrastructures différentes (comme le .NET Framework version 4 et Silverlight 4 ).

Le schéma suivant montre une application multicouche qui utilise des bibliothèques de classes Services RIA pour partager le code. La couche intermédiaire et la couche client utilisent des références d'assembly aux bibliothèques de classes.

Pour plus d'informations sur les bibliothèques de classes Services RIA , consultez Création de solutions de Services RIA et Procédure pas à pas : Création d'une bibliothèque de classes Services RIA.