Conseil n° 2 : Les classes provenant du « Add Service Reference »

Silverlight ne peut pas se connecter directement à une base de données, de sorte que vous n’avez pas d’autre option que de faire appel à une sorte de service Web, lequel va se connecter à la base de données pour votre compte. Autrement dit, vous allez probablement utiliser Add Service Reference pour générer des classes proxy afin d’aider votre application Silverlight à dialoguer avec ces services. Si vous écrivez un client WPF pour une application orientée services, vous allez vraisemblablement recourir aussi à Add Service Reference.

Lorsque ces classes proxy sont générées, elles implémentent INotifyPropertyChanged. Cela signifie qu’elles sont utilisables pour la liaison de données bidirectionnelle. Toutefois, le fait qu’elles ne peuvent pas être employées ne veut pas dire que vous ne devez pas les utiliser. Il s’agit d’un autre exemple de « loyauté des couches ». Ces classes sont fondamentalement des classes d’accès aux données et elles sont loyales à ce service et à l’implémentation WCF. La manière dont vous enregistrez et chargez les données n’est pas réellement liée à une Vue, mais à l’implémentation de la persistance. D’autre part, si vous y réfléchissez, WCF n’a pas vraiment à voir avec les objets, mais plutôt avec des messages. Par conséquent, le résultat renvoyé par WCF ne correspond pas vraiment à vos attentes. 

Naturellement, il peut être pratique d’employer ces objets proxy comme vos VueModèles, mais cela ne vous apportera aucun avantage lors de la maintenance, car toutes vos couches seront étroitement liées. Vos Vues sont liées directement aux opérations et messages pour le service. Si le contrat de service change, vous devez modifier votre Vue. De même, si votre Vue change, il faut modifier le service (la bonne blague !).

A moins que votre application soit vraiment simple, ces objets proxy ne sont pas non plus adaptés pour être vos Modèles. Les objets proxy sont simplement des objets de transfert des données servant à dialoguer avec le service. Les messages échangés entre votre application client Silverlight et l’application de service doivent être optimisés pour ces opérations. Ils peuvent avoir plus ou moins de données que nécessaire pour votre modèle ou, plus important, ils n’auront pas forcément la forme adaptée à vos besoins. Les messages peuvent même avoir une certaine forme qui permet de les sérialiser de manière plus compacte. 

N’oubliez pas que vos Modèles sont des objets de Modèle de domaine. Ils doivent être orientés objet (et non orientés message) et doivent représenter la mode de pensée de votre application client concernant les données qu’elle gère. Si vous employez les objets proxy de service en guide de Modèles, vous allez probablement avoir des conceptions d’objets peu amènes. Si vous utilisez ces objets comme VueModèles, non seulement vous sautez l’étape des Modèles, mais vous créez aussi une dépendance directe entre vos Vues XAML et vos services. Cela n’a rien d’une bonne recette pour la maintenance du code.