Pour la solution de départ, nous allons partir d'une simple application, implémentant déjà une architecture WCF. La base de données reste la même que les deux premiers articles.
- Une application cliente : WCFClient
- Un projet contenant les interfaces : WCFInterfaces
- Un serveur de services, qui tournera grâce à WCFSvcHost: WCFService
Au départ, seul les références nécessaires à WCF ont été implémentées dans cette solution.
Note : Le Service WCF sera hébergé via
WCFSvcHost.
Nous allons utiliser le designer Sync. pour créer notre synchronisation.
Sur le projet client, comme vous avez déjà l'habitude de le faire, nous allons rajouter un élément de type
LocalDatabase Cache, et nous configurons notre synchronisation :
Je passe sur la définition des tables à synchronisation, je vous renvoie sur le premier article pour cette partie.
Le plus important ici est la partie «
Advanced » du wizard, sur laquelle nous allons préciser que la synchronisation va se faire sur un projet serveur et un projet client :
Une fois validée, nous pouvons vérifier que le Wizard a bien réparti la synchronisation entre les deux projets :
D'une part le projet Client se retrouve avec : - Les références nécessaires pour la synchronisation cliente, avec notamment l'assembly contenant le fournisseur de synchronisation cliente (Microsoft.Synchronization.Data.SqlServerCe)
- Notez au passage que la référence Microsoft.Synchronization.Data.Server sera utile sur le client pour l'utilisation d'une classe serveur proxy.
- Un item de type BewiseSync.sync, qui contient un fichier BewiseSync.Designer.cs
- La base de données déportée, au format .sdf (Sql Server Compact Edition)
- Un Dataset représentant cette base de données en mémoire
D'autre part le projet Serveur se retrouve avec :- Les références uniquement nécessaires à la synchronisation serveur. Notez que l'assembly Microsoft.Synchronization.Data.SqlServerCe n'est pas référencée.
- Un item de type BewiseSync.Server.sync, qui contient un fichier BewiseSync.Server.Designer.cs
- Un fichier BewiseSync.Server.SyncContract.cs
Les classes générés cotés Client :
Afin de mieux comprendre et appréhender la structure, nous allons rentrer un peu dans le code généré par le Wizard Sync.
On peut noter que seuls les classes nécessaires au client qui ont été implémentées :
- La classe BewiseSyncClientSyncProvider, qui hérite simplement de SqlCeClientSyncProvider : Notre fournisseur de synchronisation client pour SQL SERVER CE.
- La classe BewiseSyncSyncAgent, qui hérite de SyncAgent : Notre orchestrateur de synchronisation.
- Enfin les classes représentants les synctables, au nombre 5 dans mon exemple.
Si on observe un peu le code, notamment le constructeur de la classe
BewiseSyncAgent :
public BewiseSyncSyncAgent(object remoteSyncProviderProxy) {
this.InitializeSyncProviders();
this.InitializeSyncTables();
this.RemoteProvider = new Microsoft.Synchronization.Data.ServerSyncProviderProxy(remoteSyncProviderProxy);
this.OnInitialized();
}
Notre constructeur prend en paramètre un type Object, au nom évocateur de remoteSyncProviderProxy.
Ce proxy va représenter notre objet proxy serveur, accessible via WCF, quelque soit le binding utilisé.
On note d'ailleurs qu'il existe dans Microsoft.Synchronization.Data, une classe représentant un ServerSyncProvider, sous forme de proxy : le ServerSyncProviderProxy, qui est utilisé dans le corps du code du constructeur.
Les classes générés coté Serveur:
Coté Serveur, nous ne serons pas surpris de ne retrouver que les classes nécessaires à la synchronisation coté serveur. Nous ne retrouvons pas de SyncAgent, celui-ci se trouvant coté client :
La classe BewiseSyncServerSyncProvider, qui hérite simplement de DbServerSyncProvider.
Les 5 SyncAdapters correspondant aux 5 syncTables à synchroniser.
Le plus intéressant reste à découvrir dans le fichier
BewiseSync.Server.SyncContract.csTout d'abord on y trouve une interface, taguée de multiples attributs, typique à WCF :
IBewiseSyncSyncContract.Cette interface contient 4 méthodes nécessaires à notre syncagent :
- ApplyChanges ()
- GetChanges ()
- GetSchema ()
- GetServerInfo ()
Ensuite une classe
BewiseSyncSyncService, implémentant l'interface
IBewiseSyncSyncContract.
Cette classe ne fait qu'encapsuler l'appel des méthodes de la classe
BewiseSyncServerSyncProvider, ce choix d'implémentation restant le choix fait par l'équipe de développement du Wizard Sync ;)
Enfin on peut aussi noter l'effort de génération du Wizard Sync, qui nous propose même de récupérer le code XML généré pour l'implémentation de notre service coté serveur ;)
// *** TODO: ***
// To expose this service as an endpoint add the following to the services section of the app.config file
//
// <service name="WCFService.BewiseSyncSyncService" behaviorConfiguration="WCFService.BewiseSyncSyncServiceBehavior">
// <host>
// <baseAddresses>
// <add baseAddress ="http://localhost:8080/BewiseSyncSyncService/"/>
// </baseAddresses>
// </host>
// <endpoint address ="" binding="wsHttpBinding" contract="WCFService.IBewiseSyncSyncContract"/>
// <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
// </service>
//
// and the following to the serviceBehaviors section
//
// <behavior name="WCFService.BewiseSyncSyncServiceBehavior">
// <serviceMetadata httpGetEnabled="True" />
// <serviceDebug includeExceptionDetailInFaults="False" />
// </behavior>