上一篇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

具体代码的使用如下：

1.  建立SyncDB数据库，执行Data.edmx.sqldemoData.sql建立表和数据

2.  启动SqlWebSvc服务

3.  启动SyncClient

a)  先Provison服务端数据库，定义出同步的表和条件[只要一次即可，需要修改可以DeProvision或使用1的步骤重建]

b)  此时可远程同步[界面的中其他本地同步、架构建立只是说明]

c)   快照：只要有一个同步好的数据库,这个文件就可以拷贝到其他的客户端，对于大数据量的初始化很有用

总结：

Ø  数据的Provision和Deprovision简单

Ø  代码稍微多一些

总结：

Ø  数据的Provision和Deprovision需要通过脚本编写，采用SQL Server Tracking或自定义的形式

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.