数码并框架MS Sync Framework-不同场景下例子和概括分析

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

图片 1

运作效果使齐图,可以拓展SQL、SQLCE数据库的竞相协同

Sync101RCA_Cached和任何例子展示了Provider等的贯彻,可参看其中的证实

主导以

利用这个框架进行数据库同步涉及的几只地方:

Ø Provisioning:对数据库架构和情节展开改动为记录修改的内容,为一起做准备

Ø Synchronizing:同步过程,利用上述的信息进行信息之传递

Ø
Snapshot:在一个同步好之数基础及树立快照,这样任何的客户端可迅速的安排

几单场景的例证

详尽代码参考:http://cid-56b433ad3d1871e3.office.live.com/self.aspx/.Public/SyncTest.rar 

具体代码的利用如下:

Database

N-Tier的同,SQl Server和SQL CE

Contracts: 接口定义

SqlWebSvc:WCF服务

SyncClient:客户端端

1.  建立SyncDB数据库,执行Data.edmx.sqldemoData.sql建立表和数据
2.  启动SqlWebSvc服务
3.  启动SyncClient
a)  先Provison服务端数据库,定义出同步的表和条件[只要一次即可,需要修改可以DeProvision或使用1的步骤重建]
b)  此时可远程同步[界面的中其他本地同步、架构建立只是说明]
c)   快照:只要有一个同步好的数据库,这个文件就可以拷贝到其他的客户端,对于大数据量的初始化很有用
   
   
 
总结:
Ø  数据的Provision和Deprovision简单
Ø  代码稍微多一些

Database2

类似CustomerProvider的同步

数据库Provision在Custome_SyncSamplesDb.sql建立

WCFService:服务端

SyncClient:客户端

1. 使用Custome_SyncSamplesDb.sql建立数据库和表

2. 运行WCFService

3. 运行SyncClient,可以看到同步的信息

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

DBCache-IDE

VS IDE提供的支持,编程模型更简单

DataService:服务端

PresentationTier:客户端

1. 使用Northwind.sql建立数据库和表

2. 运行DataService服务

3. 运行PresentationTier

总结

Ø 提供了一系列的设置简化同步操作

Ø 只能针对SQL Server系列的数据库

Offline

SDK中Synchronizing Databases /Offline-Only Scenarios的例子

Tracking Changes in the Server Database

Use a Custom Change Tracking System

展示了以上两种跟踪变化的形式

Custome_SyncSamplesDb.sqlCustomeChangeTrack.cs

SqlServer_ChangeTracking.sqlSqlserverChangeTrack.cs

以上的脚本和代码配合可以完成同步的过程,通过这个可以了解更多的实现细节,对自定义Provider提供一些帮助

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%5CMicrosoft%20SDKs%5CMicrosoft%20Sync%20Framework%5C2.1%5CDocumentation%5C1033%5CSyncSDK_v2.1.chm::/html/f61efb90-92a3-c2f0-ef90-27faecc5e2a5.htm)
and
SqlCeSyncProvider%5CMicrosoft%20SDKs%5CMicrosoft%20Sync%20Framework%5C2.1%5CDocumentation%5C1033%5CSyncSDK_v2.1.chm::/html/6e151204-4f3d-7057-053b-99adb9bfdb11.htm)
both inherit from
RelationalSyncProvider%5CMicrosoft%20SDKs%5CMicrosoft%20Sync%20Framework%5C2.1%5CDocumentation%5C1033%5CSyncSDK_v2.1.chm::/html/ab7c7f03-2659-355e-c660-3c6ce722f179.htm),
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.

  4. The proxy detects that changes are batched so it calls
    DownloadBatchFile by passing the batch file name as an argument.

  5. 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.

  6. 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.

  7. The proxy returns the context back to the orchestrator.

  8. 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:

  3. Removes the complete path information and sends only the file name
    over the network.

  4. Calls HasUploadedBatchFile to determine if the file has already been
    uploaded. If it has, step C is not necessary.

  5. 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.

  1. Calls ApplyChanges on the service.

  2. 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.

  3. The server passes the DbSyncContext to local SqlSyncProvider.

  4. Repeat steps 1 through 6 until the last batch is sent.

相关文章