我正在构建一个 .NET 客户端应用程序(C#、WinForms),它使用 Web 服务与数据库进行交互。客户端将使用 WAN 或 VPN 从远程位置运行,因此使用 Web 服务而不是直接访问数据库的想法。
我现在正在努力解决的问题是如何处理数据库并发。即如果两个不同位置的人更新了相同的数据,我该如何处理呢?我正在考虑在每个数据库记录上使用时间戳并将其作为更新 where 子句的一部分,但这意味着时间戳必须通过 Web 服务接口来回移动,这看起来有点难看。
解决这个问题的最佳方法是什么?
我正在构建一个 .NET 客户端应用程序(C#、WinForms),它使用 Web 服务与数据库进行交互。客户端将使用 WAN 或 VPN 从远程位置运行,因此使用 Web 服务而不是直接访问数据库的想法。
我现在正在努力解决的问题是如何处理数据库并发。即如果两个不同位置的人更新了相同的数据,我该如何处理呢?我正在考虑在每个数据库记录上使用时间戳并将其作为更新 where 子句的一部分,但这意味着时间戳必须通过 Web 服务接口来回移动,这看起来有点难看。
解决这个问题的最佳方法是什么?
我认为您不希望您的 Web 服务直接与数据库对话。您可能希望您的服务与某种类型的业务组件交互,这些组件又与数据访问层交互。任何并发异常都可以从 DAL 传递到可以处理它们的业务层,这样 Web 服务就不必查看时间戳。
但是,如果您将数据表之类的内容传递给客户端,并且想要避免时间戳,则可以通过逐个字段比较来进行并发检查。如果您要求乐观并发检查,默认情况下,表适配器向导会生成这种类型的并发检查。
如果您的冲突很少发生以至于可以手动解决,一个简单的解决方案是添加一个更新触发器,将行的更新前值复制到审计表中。这样,最近的写入是“赢家”,但不会因覆盖而丢失任何数据,管理员可以恢复较早的行状态,甚至将它们组合起来。
这种技术有其缺点,在频繁覆盖的情况下不是一个很好的解决方案。
此外,这有点离题,但使用 Web 服务不一定是要走的路,因为客户端将远程连接到网络中。ASP.NET Web 服务是基于 XML 的并且非常冗长。如果您的客户端应用程序可以指望始终保持连接,那么您最好不要使用 Web 服务。