Partage de code

modèles Vue interagissent parfois les uns avec les autres. Dans notre exemple, le modèle Vue de connexion crée le modèle Vue utilisateur.

Notez que la couche métier logique apparaît à la fois côté .NET et côté Silverlight. Je conserve généralement les fichiers communs côté .NET et le projet Silverlight accède à ceux-ci au moyen de liens. Les fichiers liés existent uniquement à l’emplacement principal et toute modification de ceux-ci sont répercutées dans tous les assemblys. Dans l’Explorateur de solution (Solution Explorer), vous créez les liens en cliquant avec le bouton droit de la souris sur le projet et en sélectionnant Add/Existing Item, puis en accédant à son emplacement réel. Une fois que vous avez sélectionné les fichiers, utilisez la flèche vers le bas du bouton Add pour sélectionner Add As Link.

Alors que le partage de certains types de code entre le serveur et les assemblys Silverlight sera souhaitable, ce ne sera pas approprié pour d’autres types de code. Par exemple, les pipelines synchrones et asynchrones pour la connexion seront utilisés chacun d’un seul côté. Vous pouvez partager une partie d’une classe tout en isolant d’autres parties avec des classes partielles. Les fichiers User Services.Silverlight et UserServices.Server files contiennent la partie de la classe UserServices qui doit exister sur une seule plate-forme. Il est inutile de créer du code spécifique à la plate-forme pour la classe de données, par conséquent elle n’a pas de classes partielles associées.

L’affichage d’un message lors de l’échec de la connexion illustre la puissance de la liaison de données Silverlight (ou WPF). Au lieu que la vue effectue sa propre détermination, vous pouvez ajouter une propriété Boolean au modèle Vue de connexion qui indique une tentative non valide, et ajouter une propriété string pour le message. La liaison au texte est simple, mais la propriété visibility est une énumération qui est spécifique à Silverlight et non un booléen. Il est possible d’utiliser un convertisseur de valeur Silverlight pour combler le fossé entre ces deux types et maintenir une isolation appropriée :

Grid.Row="3" Grid.Column="1" Grid.ColumnSpan="2"
Text="{Binding Path=InvalidMessage}"
Visibility="{Binding Path=InvalidAttempt,
Converter={StaticResource VisibilityConverter}}
"/>

Il existe un certain nombre de détails qui peuvent vous faire trébucher lorsque vous construisez cette architecture. Dès que vous créez la référence au service, ServiceReferences.ClientConfig est généré dans l’assembly qui contient la référence en question. Toutefois, le fichier de configuration client doit être disponible dans l’assembly Silverlight principal, de sorte que vous devez ajouter un lien vers ce fichier. En raison du grand nombre d’éléments qui constituent une application Silverlight, une bonne convention de nommage est essentielle. Ajoutez un suffixe supplémentaire pour clarifier le but des projets et des classes partielles. Vous devrez supprimer manuellement ce suffixe de l’espace de noms spécifié dans les propriétés du projet.

Peu importe la complexité du pipeline que vous avez choisi, mettez-le en place et soyez clair avec votre équipe concernant les emplacements de la logique, des assemblys et des limites de service. Si vous ne comprenez pas les limites envisagées, il sera impossible de maintenir une architecture cohérente. Il faudra également clarifier les emplacements des données. Sur la figure 1, les données sont à l’extérieur du pipeline et résident dans des objets de données passés le long du pipeline (comme illustré sur la partie gauche du schéma).

Comme la testabilité est également une mesure de composabilité et de séparation des problèmes, soyez certain de comprendre où se trouvent les limites des tests et, au moment de prototyper votre architecture, écrivez au minimum suffisamment de tests pour garantir la validité de ces limites. Les flèches jaunes et vertes sur le côté droit de la figure 1 indiquent les limites des tests planifiés. Les flèches jaunes indiquent où les tests peuvent commencer dans l’application et les flèches vertes indiquent où les éléments de substitution (mock) peuvent être insérés. Notez que j’ai combiné les services métier logiques Silverlight et les références aux services (appelées proxies de service sur la figure 1) dans le même assembly, sans l’obligation d’employer une substitution. Autrement dit, la logique métier côté Silverlight ne peut pas être testée sans faire appel à un service WCF, même si ce service WCF peut être un service de substitution fournissant des données de simulation. Dans l’idéal, chaque coupure logique doit être testable, mais l’architecture n’est pas une sculpture parfaite seulement destinée à être exhibée. Il s’agit d’une solution pragmatique qui produit une application aujourd’hui et facilite la maintenance ainsi que l’évolution tout au long de la vie de l’application.