核心数据:实例化“根对象”在基于文档的应用程序中

发布于 2024-11-02 17:44:24 字数 728 浏览 0 评论 0原文

我正在使用 Core Data 创建一个基于文档的项目,并且遇到了对我来说可能只是一个概念问题,虽然我对 Cocoa 并不陌生,但这是我第一次尝试利用 Core Data。我想要完成的事情应该相对简单:随着每个新文档的启动,我希望创建一个模型对象的新实例,作为“根”对象。

我所做的是将 NSObjectController 添加到我的 xib,将其模式设置为实体名称(提供正确的实体名称),选中“准备内容”,并将其托管对象上下文绑定到文件的所有者,并使用 ManagedObjectContext 作为模型关键路径。为了测试这一点,我将主窗口的标题绑定到对象控制器,将控制器键作为选择,将模型键路径作为实体中的键之一。

我知道我可以通过编程方式创建我的根对象,但我正在尝试采用 Apple 推荐的中介模式。我已经看到了部门员工教程中“采用调解者模式”部分下的说明,并且详细的步骤正是我相信我所做的。

有什么想法吗?

编辑: 也许我没有正确地表述问题。模型是在 Core Data 中创建的,并且关系是根据我的需要设置的(具有“根”、子级和叶级,使用一对一父关系、多子关系和 isLeaf 布尔属性)。我的问题是确保每次启动新文档时都会将该根对象实例化为单例。根对象和当前文档之间应该存在精确的 1:1 关系,该根对象必须始终存在并且可用,无需任何用户交互来创建它,并且创建并附加到根的子节点是数据对象由应用程序使用和操作。

我已经以编程方式实现了上述功能,但为了与核心数据原则保持一致,我希望完全采用中介模式,而不是在我的应用程序逻辑中管理任何数据对象的创建。

I am creating a document based project using Core Data and have run into what may simply be a conceptual issue for me, as while I am not new to Cocoa, this is my first attempt to utilize Core Data. What I am trying to accomplish should be relatively simple: with each new document launched, I would like a new instance of one of my model objects created that serves as a "root" object.

What I have done is add an NSObjectController to my xib, set its mode to Entity Name (with the correct entity name provided), checked off "Prepares Content", and bound its managed object context to File's Owner with managedObjectContext as the model key path. To test this, I bound the title of my main window to the object controller, with controller key as selection and model key path as one of the keys in my entity.

I know I can create my root object programmatically, but am trying to adopt the mediator pattern as is recommended by Apple. I have seen the instructions in the department-employee tutorial under the "adopting the mediator pattern" section and the steps detailed are exactly what I believe I have done.

Any thoughts?

Edit:
Perhaps I did not state the problem correctly. The models are created in Core Data and the relationships are setup as I need them to be (with a "root", children and leaves, using to-one parent relationships, to-many children relationships and an isLeaf boolean attribute). My issue is ensuring that this root object is instantiated as a singleton every time a new document is launched. There should be exactly a 1:1 relationship between the root object and the current document, that root object must always exist and be available without any user interaction to create it, and child nodes that are created and attached to the root are the data objects that are used and manipulated by the application.

I have implemented the above functionality programatically, but in keeping with Core Data principles, would like to adopt the mediator pattern completely and not manage any creation of data objects within my application logic.

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

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

发布评论

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

评论(1

月牙弯弯 2024-11-09 17:44:24

如果您想要一个像链表或树中那样的“根”管理对象,那么您必须在数据模型本身中进行设置。

默认情况下,Core Data 数据模型在对象之间没有特定的层次结构。对象可能是相关的,但没有一个对象在逻辑上“高于”或“低于”另一个对象。您可以通过从任何其他对象开始并将关系返回到所需对象来到达任何关系中的对象。

托管对象的层次结构需要像这样的树状结构:

Tree{
    nodeName:string
    parent<-->>Tree.children
    children<<-->Tree.parent
}

...以便“根”对象是唯一具有 parent==nilTree 实例。

说了这么多,我想指出,您引用的 Apple 文档说,在大多数情况下最好使用这种类型的内置层次结构。这只是用于演示目的的一种简化(我认为这是一个糟糕的简化)。

数据模型旨在建模/模拟应用程序处理的现实世界对象、条件或事件。因此,模型/图中的实体/对象之间的逻辑关系应该反映现实世界的关系。在这种情况下,除非您正在建模的现实世界事物存在于具有现实世界“根”对象、条件或事件的层次结构中,否则您的模型也不应该有这样的层次结构。

If you want a "root" managed object like you would find in linked-list or tree, then you have to set that up in data model itself.

By default, a Core Data data model has no particular hierarchy among objects. Objects may be related but no object is logically "above" or "below" another one. You can reach in object in any relationship by starting with any other object and walking the relationship/s back to the desired object.

A hierarchy of managed objects needs a tree like structure like this:

Tree{
    nodeName:string
    parent<-->>Tree.children
    children<<-->Tree.parent
}

... so that the "root" object is the sole Tree instances that has parent==nil.

Having said all this, I would point out that the Apple docs you refer to say that it is best NOT to use this type of built in hierarchy for most cases. It's just a simplification used for purposes of demonstration (and I think it is a bad one.)

The data model is intended to model/simulate the real-world objects, conditions or events that the app deals with. As such, the logical relationships between the entities/objects in the model/graph should reflect the real-world relationships. In this case, unless the real-world things you are modeling exist in a hierarchy with a real-world "root" object, condition or event, then your model shouldn't have one either.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文