-
Notifications
You must be signed in to change notification settings - Fork 12
Home
It's a database-agnostic synchronization framework based on .NET Standard 2.0 to synchronize data between multiple clients and a single server, where both platforms are using technologies that compatible with .NET Standard 2.0, such as Xamarin Forms for the mobile clients and ASP .NET Core for the backend server.
Why oh why...
- It's based on .NET Standard 2.0, which is the latest technology (as per writing) on Microsoft stack.
- It's DATABASE-AGNOSTIC, means, it can be used with ANY KIND of database technology, as long as you can direct it (technically by subclassing its engine) to the correct implementation on how to do this-and-that in your specific database.
- Not like other synchronization frameworks, NETCoreSync doesn't use tracking tables and tombstone tables (I hate them, because most likely they will double up your row count and take storage space), BUT, you need to add some additional columns to your tables.
- Not like other synchronization frameworks, NETCoreSync doesn't use triggers (I also hate triggers, because not all database technology support triggers, and it always feels like I have some unused left-over triggers somewhere in my tables...), BUT, in your application's insert/update/delete data functions, you have to call some hook methods before persisting the data into the table.
- Support two kinds of synchronization approach: GlobalTimeStamp and DatabaseTimeStamp, where both of them will be explained below.
Data synchronization between server and clients will use the world clock (the system's Date Time) when comparing a data that exist in both source and destination, to determine whether the source data is newer or not than the destination data.
Pros:
- Simpler to implement (than the other one)
Cons:
- Relies heavily on the correctness of each system's Date Time (world clock) that will participate in the synchronization process. On servers this may be not an issue (servers usually always have correct Date Time), but in mobile clients, if for some reason your user change the phone's date to an earlier time after synchronization, the next synchronization will have conflicts in it. So this approach may be suitable if only performed between servers.
Data synchronization between server and clients will use their own internal time stamp (represented in long value) when comparing a data that exist in both source and destination. These so-called internal time stamp will correctly determine whether the source data is newer or not than the destination data, regardless of what the system's world clock is.
Pros:
- Eliminates the GlobalTimeStamp weakness, therefore more suitable to use in mobile clients.
Cons:
- Harder to implement than the other one, and, will require one additional table to keep the time stamp knowledge.
Here they come...
-
Soft Delete
Your existing database design MUST use the Soft Delete approach when deleting record from tables, means that the data is not physically deleted from the table, but only flag the record with a boolean column (such as IsDeleted) that indicates whether this record is already deleted or not.
-
Unique Primary Key
Your existing database tables must use Primary Keys that is unique, such as UUID / Guid, to ensure correct comparison of data during synchronization.
-
Data Representation as Objects
Your server and client database tables must be represented as objects in the server and client applications, known as POCO (Plain Old CLR Objects), because NETCoreSync needs to mark the object properties with some special attributes to indicate which field is the Primary Key, etc.