上一篇http://www.cnblogs.com/2018/archive/2011/02/22/1961654.html 对这个框架一个总体介绍，这篇通过SDK内带的例子和一个综合的例子描述一下这个框架的使用
[例子基于SDK2.1]
SDK的例子
C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework\2.1\Samples
WebSharingAppDemo-CEProviderEndToEnd
运行效果如上图，可以进行SQL、SQLCE数据库的相互同步
Sync101RCA_Cached和其他例子展示了Provider等的实现，可参考其中的说明
基本使用
使用这个框架进行数据库同步涉及的几个方面：
Ø Provisioning：对数据库架构和内容进行修改以记录修改的内容，为同步做准备
Ø Synchronizing：同步过程，利用以上的信息进行信息的传递
Ø Snapshot：在一个同步好的数据基础上建立快照，这样其他的客户端可以快速的部署
几个场景的例子
详细代码参考：http://cid-56b433ad3d1871e3.office.live.com/self.aspx/.Public/SyncTest.rar
具体代码的使用如下：
Code Specific To N-Tier
在SDK文档How to: Deliver Changes in Batches (SQL Server)“How to: Deliver Changes in Batches (SQL Server)”这个主题下有详细的说明，注记如下：
The remainder of the code examples apply only to the n-tier scenario in WebSharingAppDemo. The relevant n-tier code is contained in three files:
· The service contract: IRelationalSyncContract
· The Web service: RelationalWebSyncService
· The proxy: RelationalProviderProxy
The two providers SqlSyncProvider and SqlCeSyncProvider both inherit from RelationalSyncProvider, so this code applies to both providers. Additional store-specific functionality is separated into proxy and service files for each type of provider.
To understand how batching works in an n-tier scenario, consider a synchronization session in which the server is the source and the client is the destination. After changes have been written to the local directory on the server, the following process occurs for downloaded changes:
1. The GetChangeBatch method is called on the client proxy. As demonstrated later in the sample code, this method should include specific code to handle batching.
2. The service gets a batch file from SqlSyncProvider. The service removes the complete path information and sends only the file name over the network. This prevents exposing the directory structure of the server to the clients.
3. The proxy call to GetChangeBatch returns.
1. The proxy detects that changes are batched so it calls DownloadBatchFile by passing the batch file name as an argument.
2. The proxy creates a unique directory (if one doesn’t exist for the session) under RelationalProviderProxy.BatchingDirectory to hold these batch files locally. The directory name is the replica ID of the peer that is enumerating changes. This ensures that the proxy and service have one unique directory for each enumerating peer.
4. The proxy downloads the file and stores it locally. The proxy replaces the filename in the context with the new full path to the batch file on the local disk.
5. The proxy returns the context back to the orchestrator.
6. Repeat steps 1 through 6 until the last batch is received by proxy.
The following process occurs for uploaded changes
1. The orchestrator calls ProcessChangeBatch on the proxy.
2. The proxy determines that it is a batch file, so it performs the following steps:
1. Removes the complete path information and sends only the file name over the network.
2. Calls HasUploadedBatchFile to determine if the file has already been uploaded. If it has, step C is not necessary.
3. If HasUploadedBatchFile returns false, calls UploadBatchFile on the service, and uploads the batch file contents.
The service will receive the call to UploadBatchFile and store the batch locally. Directory creation is similar to step 4 above.
4. Calls ApplyChanges on the service.
3. The server receives the ApplyChanges call and determines that it is a batch file. It replaces the filename in the context with the new full path to the batch file on the local disk.
4. The server passes the DbSyncContext to local SqlSyncProvider.
5. Repeat steps 1 through 6 until the last batch is sent.