核心数据:在属性更改时触发长时间运行的操作

发布于 2024-11-03 22:32:44 字数 728 浏览 1 评论 0原文

我的模型中有一个对象,修改时需要大量其他对象根据这些更改重新计算值。

目前的设置方式是,该对象只能在一处进行修改。这是一个带有“取消”和“确定”按钮的工作表。用户提交更改后,工作表将显示进度条并开始处理受更改影响的对象。工作表的呈现和解除都包含在 NSUndoManager 组中。用户可以在关闭该工作表后一次性撤消所有更改。

让我困扰的是,我一直认为这一切都应该发生在业务层面。而不是在控制器级别。即,我应该能够在 UI 和代码中的任何位置修改我的业务对象,并让它触发必要的计算。

因此,我会设置 KVO 来监视我的对象并在需要时触发长时间运行的操作。一旦我沿着这条路走下去,我就开始碰壁。

  • 如何合并更改?我的对象有几个属性。当第一个属性更改并且第二个属性接下来可能会更改时,我不想开始计算。基本上我需要一个编辑表和一些控制点来一次提交所有更改。

  • 如何向这个长时间运行的操作添加 UI?我可以将 NSOperationQueue 附加到 NSManagedObjectContext 并让我的窗口控制器观察它。当队列不为空时,我会弹出一个带有进度条的工作表,监视当前操作。

  • 如何实现撤消/重做支持?如果我延迟重新计算到事后运行的操作,我无法想象如何同时撤消初始更改和传播一次。我只能想象撤消原始更改并触发对所有其他对象的另一次重新评估。

简而言之:

这种依赖关系的最佳实践是什么?

传播是模型层的工作还是控制层的工作?

I have in my model an object, that when modified requires a large number of other objects to recompute values based on those changes.

The way this is currently set up, is that this one object can only be modified in one place. This is a sheet with a Cancel and an OK button. Once the user commits the change, the sheet shows a progress bar and starts processing the objects affected by the change. The presentation and dismissal of the sheet are wrapped in a NSUndoManager group. The user may undo all changes in one pass after dismissing the sheet.

What bothers me is that I keep thinking that all this should happen at the business level. Rather than at the controller level. I.e. I should be able to modify my business object any place in the UI and code and have it trigger the necessary computations.

So I would set up KVO to watch my object and trigger the long running operation when needed. Once I go down that path, I start hitting walls.

  • How do I coalesce changes? My object has several attributes. I don't want to start a computation when the first attribute is changed and the second is likely to change next. Basically I need an edit sheet and some control point to commit all changes at once.

  • How do I add a UI to this long running operation? I could have an NSOperationQueue attached to the NSManagedObjectContext and have my window controller observe that. When the queue is not empty, I would pop up a sheet with a progress bar monitoring the current operation.

  • How can I implement Undo/Redo support? If I delay recomputation to an operation running after the fact, I cannot imagine how to undo the initial change and the propagated once at the same time. I can only imagine undoing the original change and having that trigger another reevaluation of all other object.

In short:

What is the best practice for such dependancies?

Is the propagation a job for the model layer or the control layer?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟花易冷人易散 2024-11-10 22:32:44

我相信我想出了一个解决方案:

  • 中心模型对象监视自身的变化
  • ,它创建或修改一个 ToDo 对象,
  • 控制器监视新的 ToDo 对象
  • ,控制器使 ToDo 出队,显示进度条并执行手术

I believe I came up with a solution:

  • the center-piece model object watches itself for changes
  • on change, it creates or amends a ToDo object
  • the controller watches for new ToDo objects
  • the controller dequeues the ToDo, presents a progress-bar and performs the operation
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文