.NET 的离线同步选项
我被要求研究处理我们要构建的应用程序的方法。该应用程序假设是用 C# 编写的 Windows 窗体，如果已连接，将直接向服务器发出命令，但如果应用程序处于离线状态，则必须保持状态，就像已连接一样，然后同步并向服务器发出数据更改/命令服务器连接后。
我不知道从哪里开始寻找。这与 Google Gears 类似，但我认为如果我们走 Winform 路线，我就没有这个选择（这看起来很可能，因为应用程序需要一些 Web 应用程序无法执行的其他功能）。 Microsoft Sync 框架是一个可行的选择吗？ Silverlight 有类似的功能吗？还有其他选择吗？我在谷歌上搜索了一下，但希望社区能够就该场景的最佳方案提供意见。
I've been asked to research approaches to deal with an app we're supposed to be building. This app, hypothetically a Windows form written in C#, will issue commands directly to the server if it's connected, but if the app is offline, the state must be maintained as if it was connected and then sync up and issue data changes/commands to the server once it is connected.
I'm not sure where to start looking. This is something akin to Google Gears, but I don't think I have that option if we go a Winform route (which looks likely, given that there are other functions the application needs that a web app couldn't perform). Is the Microsoft Sync framework a viable option? Does Silverlight do anything like this? Any other options? I've Googled around a bit but would like the community input on what's best given the scenario.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Microsoft Sync Framework 绝对支持您描述的场景，尽管我想说让它工作相当复杂。
关于 Sync Framework 需要了解的一件事是，它实际上是在同一个包中提供的两个截然不同的框架：
ADO.NET Sync services 是迄今为止最容易设置的，但它们仅限于同步两个关系数据存储（尽管您可以将 Web 服务设置为两者之间的远程外观）。
核心同步框架没有这样的限制，但实现起来要复杂得多。当我大约六个月前使用它时，我发现最好的学习来源是 SDK，特别是文件/文件夹同步示例代码。
据我所知，这两个“框架”之间几乎没有共享代码和类型，因此您必须选择其中之一。
无论哪种情况，托管同步代码的方式都没有限制，因此 Windows 窗体只是众多选项中的一个。
The Microsoft Sync Framework definitely supports the scenario you describe, although I would say that it's fairly complicated to get it working.
One thing to understand about the Sync Framework is that it's really two quite distinct frameworks shipping in the same package:
The ADO.NET Sync services are by far the easiest to set up, but they are constrained to synchronizing two relational data stores (although you can set up a web service as a remote facade between the two).
The core Sync Framework has no such limitations, but is far more complex to implement. When I used it about six months ago, I found that the best source to learn from was the SDK, and particularly the File/Folder sync sample code.
As far as I could tell, there was little to no sharing of code and types between the two 'frameworks', so you will have to pick one or the other.
In either case, there are no constraints on how you host the sync code, so Windows Forms is just one option among many.
如果我理解正确的话，这对我来说听起来不像是您想要保持两个数据库同步的实际数据同步问题。听起来更像是您想要一种可靠的机制，让客户端在连接不稳定的环境中调用服务器上的函数，并且如果当时不存在连接，您希望连接恢复后立即调用该函数向上。
如果我的理解是正确的，这是一种选择。如果没有，这可能不会有帮助。
这是对一个深入问题的非常简短的回答，但我们也遇到过类似的情况，这就是我们的处理方式。
我们有一个客户端应用程序需要监视商店中 PC 上的一些数据。当某些事件发生时，该客户端应用程序需要更新我们在公司办公室的服务器，最好是实时更新。但是，连接并不是 100% 可靠，因此我们需要类似的机制。
我们通过尝试通过 Web 服务写入服务器来解决这个问题。如果调用 Web 服务时出现错误，该命令将被序列化为名为“等待上传”的文件夹中的 XML 文件。
我们在客户端应用程序中运行一个例程，定时器设置为每 n 分钟一次。当计时器到时，它会检查此文件夹中是否有 XML 文件。如果找到，它会尝试使用文件中保存的信息调用 Web 服务，依此类推，直到成功。成功调用后，XML 文件将被删除。
这听起来很黑客，但它的编码很简单，并且已经完美运行了五年。它实际上是我们最无故障的应用程序，并且我们已经在其他地方成功实现了该模式
If I understand correctly, this doesn't sound like an actual data synchronization issue to me where you want to keep two databases in sync. it sounds more like you want a reliable mechanism for a client to call functions on a server in an environment where the connection is unstable, and if the connection is not present at the time, you want the function called as soon as the connection is back up.
If my understanding is right, this is one option. if not, this will probably not be helpful.
This is a very short answer to an in-depth problem, but we had a similar situation and this is how we handled it.
We have a client application that needs to monitor some data on a PC in a store. When certain events happen, this client application needs to update our server in the corporate offices, preferably Real-Time. However, the connection is not 100% reliable, so we needed a similar mechanism.
We solved this by trying to write to the server via a web service. If there is an error calling the web service, the command is serialized as an XML file in a folder named "waiting to upload".
We have a routine running in our client app on a timer set for every n minutes. When the timer elapses, it checks for XML files in this folder. If found, it attempts to call the web service using the information saved in the file, and so on until it is successful. Upon a successful call, the XML file is deleted.
It sounds hack-ish, but it was simple to code and has worked flawlessly for five years now. It's actually been our most trouble-free application all-around and we've implemented the pattern elsewhere successfully