嵌套 UI 需要 ActiveRecord 中的嵌套事务
我有一个编辑模型类型 M1 的对话框 D1，还有一个编辑模型类型 M2 的对话框 D2。 M2 包含的内容之一是对 M1 的引用，因此为了方便用户，除了可以从顶层访问 D1 和 D2 之外，D2 还包含启动 D1 的按钮。
D1 和 D2 各自在入口处创建一个 TransactionScope（使用 TransactionMode.New），在用户与对话框交互时修改模型对象（M1 或 M2），然后提交当用户按下“确定”/“取消”按钮时适当地 /rollback。
当从顶层打开对话框时，这可以单独工作。
当从 D2 中打开 D1 时，预期的行为是在 D1 中单击“确定”应立即保存到数据库，然后 M1 中的更改应对 D2 可见。 （然后，D2 可以保存或取消对 M2 的更改，而不会影响 M1。）
实际发生的情况是，当 D1 关闭时（以及 D2 关闭之前），对 M1 的更改似乎确实保存到数据库中，但 D2 不能查看 M1 的更改 - 大概是因为 D2 中的会话/事务认为它具有最新的对象，因此不会重新查询数据库，即使调用 FindFirst 等时也是如此。有没有办法强制它（不丢失对 M2 的更改）？
（另一个奇怪的行为是，D1 和 D2 都挂接到 TransactionScope.OnCompleted 上，但这仅在 D2 关闭（从 D2 调用 D1 的情况下）时在 D1 上触发。）
I have a dialog D1 which edits model type M1, and another dialog D2 which edits model type M2. One of the things that M2 contains is a reference to an M1, and so as a convenience to the user D2 contains a button that launches D1, in addition to both D1 and D2 being accessible from the top level.
Each of D1 and D2 create a TransactionScope (using TransactionMode.New) on entry, modifies the model objects (M1 or M2) as the user interacts with the dialog, and commit/rollback as appropriate when the user presses the OK/Cancel buttons.
This works fine in isolation, when the dialogs are opened from the top level.
When D1 is opened from within D2, the expected behaviour is that clicking OK in D1 should immediately save to the database and the changes in M1 should then become visible to D2. (D2 can then save or cancel its own changes to M2 without affecting M1.)
What's actually happening is that the changes to M1 do seem to be getting saved to the database when D1 closes (and before D2 closes), but D2 can't see the changes to M1 -- presumably because the session/transaction in D2 thinks that it has the up-to-date objects so doesn't requery the database, even when FindFirst etc get called. Is there some way to force it (without losing the changes to M2)?
(Another weird behaviour is that both D1 & D2 hook on to TransactionScope.OnCompleted, but this only fires on D1 when D2 is closed for the case when D1 is called from D2.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，我想我已经找到了一些有用的东西，但它有点丑陋，所以我仍然对任何更好的答案感兴趣。
诀窍是修改 D1，以便当它被嵌套调用时，在提交自己的事务（从而返回到 D2 的事务范围）之后，重新
查找它刚刚修改的对象并刷新他们。它可以检测到它处于这种嵌套场景中，因为当它
Dispose处理自己的事务时，OnCompleted没有被调用。（此解决方案的问题之一是，它可能不适用于三层嵌套场景，除非最内层可以将其修改对象列表一直传递到最外层，这变得非常难看。幸运的是我的情况只需要两层。）
Ok, I think I've found something which works, but it's a bit ugly, so I'm still interested in any better answers.
The trick was to modify D1 such that when it's being called nested, after committing its own transaction (and thereby returning to D2's transaction scope), to re-
Findthe objects it just modified andRefreshthem.And it can detect that it's in this nested scenario because
OnCompleteddidn't get called when itDisposed its own transaction.(One of the problems with this solution is that it presumably wouldn't work for a three-layer nesting scenario, unless the innermost layer could pass its list of modified objects all the way to the outermost layer, which gets really ugly. Fortunately in my case I only needed two layers.)