Data synchronization framework Ms sync framework-Use Cases and brief analysis in different scenarios

The previous http://www.cnblogs.com/2018/archive/2011/02/22/1961654.html gave a general introduction to this framework, this example of using the SDK and a comprehensive example to describe the use of this framework

[The example is based on sdk2.1]

SDK example

C: \ Program Files (x86) \ microsoft sdks \ microsoft sync framework \ 2.1 \ Samples

Websharingappdemo-ceproviderendtoend

For example, you can synchronize SQL and sqlce databases.

Sync101rca_cached and other examples demonstrate the implementation of providers. For more information, see the description.

Basic usage

Using this framework for Database Synchronization involves the following aspects:

Provisioning: modifies the database architecture and content to record the modified content and prepare for synchronization.

Ø synchronizing: In the synchronization process, information is transmitted using the above information.

Ø snapshot: Create snapshots based on a synchronized data so that other clients can be quickly deployed.

Examples of scenarios

DetailsCodeReference: http://cid-56b433ad3d1871e3.office.live.com/self.aspx/.Public/SyncTest.rar

The Code is as follows:

database N-tier, SQL Server and SQL ce	contracts: interface Definition sqlwebsvc: syncclient: client 1. create a syncdb database and execute data. edmx. sqldemodata. SQL creates tables and data 2. start the sqlwebsvc service 3. start syncclient A) First provison the server database, and define the synchronized table and condition [only once, you can modify deprovision or use step 1 to recreate it.] B) in this case, you can remotely synchronize [other local synchronization and architecture creation on the interface] C) snapshots: as long as there is a synchronized database, this file can be copied to other clients, which is useful for large data volume initialization summary: ø simple data provision and deprovision ø slightly more code
database2 synchronization similar to customerprovider	database provision is created in custome_syncsamplesdb. SQL wcfservice: server syncclient: client 1. use custome_syncsamplesdb. SQL to create a database and a table 2. run wcfservice 3. run syncclient to view the synchronization information. conclusion: ø the provision and deprovision of data must be written in a script, use SQL Server tracking or custom form
dbcache-ide vs ide support, simpler Programming Model	dataservice: server presentationtier: client 1. use northwind. SQL database and table creation 2. run dataservice service 3. run presentationtier conclusion ø provides a series of settings to simplify synchronization Operations ø only SQL Server databases
Offline Example of synchronizing databases/offline-only scenarios in SDK	Tracking changes in the server database Use a custom change tracking system Demonstrate the above two forms of tracking changes Custome_syncsamplesdb.sqlcustomechangetrack.cs Sqlserver_changetracking.sqlsqlserverchangetrack.cs The above script and code can be used together to complete the synchronization process. Through this, you can learn more implementation details and provide some help to the custom provider.

Code specific to n-tier

Detailed descriptions are provided in the SDK documentation "How to: deliver changes in batches (SQL Server)" How to: deliver changes in batches (SQL Server) ". The notes are as follows:

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 shoshould 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 calldownloadbatchfile 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 already ed by proxy.

The following process occurs for uploaded changes

1. The orchestrator cballs 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. callhasuploadedbatchfile to determine if the file has already been uploaded. If it has, Step C is not necessary.

3. If hasuploadedbatchfile returns false, calluploadbatchfile 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 abve.

4. callapplychanges on the service.

3. The server has es 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.