桌面应用程序，可以离线工作时，没有连接到SQL Server

您可以找出SQL Server连接丢失时产生的特定异常，并将调用嵌入try-catch块中。如果服务器离线，那么在catch块中，将实体传递给一个方法，该方法将实体序列化为JSON并将其保存到硬盘驱动器中的特殊目录或其他地方。在下一次成功查询时，检查该目录，看看是否有任何需要保存的实体。

明确你的捕获——你不希望不相关的异常触发这段代码。

一些事情要记住——如果有人在此期间更改了数据怎么办?您打算覆盖这些更改吗?如果您处于离线状态，您如何获得首先需要保存的数据?

只要您已经将所有数据加载到DbContext/ObjectContext中，您就可以随意修改这些数据。只有在调用SaveChanges()时，才真正需要连接。

但是，如果要将所有内容加载到上下文中，则似乎需要重新实现DataSet功能，此外，还允许对更改进行xml序列化/反序列化，因此甚至可以在会话之间保存更改。

不像EF那么流行:)

虽然我从未对基于sql的数据尝试过这种方法，但我过去曾对基于文件系统的数据这样做过，这是一个主要的问题。

首先，您必须有一些方法来指示需要在本地存储哪些数据，以便在脱机时可以使用。这将需要一直更新，或者在你出发之前更新——这可能涉及到大量的数据传输。

第二，一旦你重新上线，有很多冲突必须解决。如果在您外出时，其他人很可能更改了数据，那么您需要某种方法来检测冲突，并提示用户在这种情况下该怎么做。这几乎肯定需要一个系统，对每一个可以合理更新的数据单元保持详细的编辑跟踪。

在我的情况下，我非常幸运，因为它几乎可以肯定，如果远程用户编辑文件[x]，覆盖系统副本是正确的事情。远程用户将只携带与他们的项目有关的文件，不应该发生冲突。因此，回写只是基于时间戳，仅此而已。在这个领域工作的人通常不需要修改的数据，他们甚至不看一眼就处理了，修改后的文件只是从系统复制到笔记本电脑。

剩下中间的步骤——保存挂起的写操作。在这方面，我不同意Elemental Pete的回答——简单地序列化它们并保存结果，不能工作，因为当您再次读取数据时会发生什么?你看到的是旧的副本，而不是修改过的副本!

我的方法是在本地存储所有相关数据，这些数据的访问方式与主系统数据完全相同，所有的读写操作都正常进行。

如果您的数据需要涉及事务，则可能需要一些更花哨的东西。

请注意，我们还遇到了一个严重的人为问题:更新过程花了几分钟(注:>10年前)仅仅分析需要做什么，没有计算任何实际的复制时间。其结果是，当人们认为可以绕过它时，他们就会绕过它。有时候他们想错了，哎呀!