entity-framework - Entity Framework - 基础数据(在数据库中)更改通知

Question

到目前为止，我正在使用 Entity Framework 成功地操作数据库中的数据。

但是，我希望有多个应用程序同时处理数据(并发版本)。

有没有办法在数据库中的数据发生变化时得到通知？

我看到了一个使用 DML 触发器的解决方案，但我想知道是否有其他方法可以实现这一目标，如果有，最好的解决方案是什么。

问候，

网卡

编辑

也许我的问题不够清楚，我会尝试通过一个例子来说明它。

应用程序#1 正在数据库#1 上使用 Entity Framework

应用程序#2 也在数据库#1

上使用 Entity Framework

应用程序#1 更改了实体模型，这反射(reflect)在数据库#1 的基础表中的更改

我希望应用程序#2 收到有关此更改的通知，以便它可以拥有一致/更新的数据。

Answer 1

也许您应该考虑在您的应用程序中使用 EF。 EF 的上下文应使用尽可能短的时间:

创建上下文

加载数据

修改数据

保存数据

删除上下文

由于内部实现(IdentityMap、UnitOfWork)长期存在的上下文不是一个好的选择，并且在短期存在的上下文中，您根本不希望提及行为。即使在桌面应用程序中，您也应该使用每个表单的上下文等方法。您加载数据，将数据呈现给您的用户，直到那时只有用户才能修改数据并按下保存按钮 - 以某种方式处理并发问题(时间戳)是应用程序的责任。自动修改作为运行工作单元一部分的数据是一个非常糟糕的主意 - 如果用户已经修改了数据怎么办？你会覆盖他的改变吗？

编辑:

您可以阅读更多关于执行 ObjectContext 的信息 here .

我可以想象需要向客户端应用程序发送数据更新通知的场景。它可以是只读的实时数据显示——例如股票交易信息。但在这种情况下，你需要更强大的东西。这不是客户端调用 ORM 来获取数据的场景，而是客户端订阅一些处理数据检索和快速更改通知的服务/中间层的场景。

对于只需要以半实时方式刷新数据的简单场景，您可以使用轮询 - 您的客户端将在几秒钟内再次调用查询并使用 StoreWins战略。任何通知策略都超出了 EF 的范围 - 您必须将其实现为触发器、sql 依赖项、发布订阅模式或其他东西。即使有通知，您也只能处理某些事件并重新查询数据。

同样，如果您想通过轮询来减少数据传输，您需要一些服务/中间层来允许某种级别的缓存(您也可以尝试 WCF 数据服务)。