是否让NSManagedObject成为一个良好的实践？

任务的详细信息：是否让NSManagedObject成为一个良好的实践？

我正在开发与1-30硬件设备同时进行通信的应用程序，每个设备都有它自己的TCP连接。

因此，我创建了一个实体“hardwareObject”，它将表示该设备的某些属性，例如，值1和值2。

我创建了一个连接处理程序类，我定义为我的“hardwareObject”实体的瞬态属性。在UI更改上，核心数据对象被修改，并且核心数据对象本身通知它的连接发送value1或value2的更改。

当新数据通过委托方法到达时，我想通知一个“hardwareObject”的实例，因此它是它的属性的委托。

我想知道是否让NSManagedObject成为s.th的代表。是一个很好的做法？

可能会导致有关故障或其他核心数据相关事情的任何问题？或者我应该更好地创建一个sharedInstance主连接处理程序对象，它负责处理每个连接处理程序并仅在需求时与我的核心数据对象通话？

来源

2012-02-11 b00tsy

这是一个完全有效的设计。 NSManagedObjects可以由它们的（托管对象）上下文来管理，但是如果你保留一个NSManagedObject，它将保持有效，并且你可以自由地在该类中实现任何特殊的业务逻辑，或者使它成为一个委托。事实上，Core Data允许您继承NSManagedObject的其中一个重要方面就是您可以执行这些操作。

如果需要从上下文中删除对象，请确保将您的类作为委托注销。

来源

2012-02-12 07:23:32

你建议然后保留委托属性，而不是分配它，以保持NSManagedObject的子类“活着”？ – b00tsy 2012-02-13 08:07:17

每当你有一个'obj <->委托'关系时，你需要确保两端（obj和委托）保持有效，只要两者都有相互关系。 * classic *方法是委托人保留obj的方法（例如，视图控制器保留表视图）并且obj对委托的引用很弱（表视图对视图控制器的引用很弱）。您也可以使用它，但是您需要确保托管对象在其消失时（在“-didTurnIntoFault”内部）将它自己设置为委托。否则，你会有悬挂指针。 – 2012-02-13 09:45:55

这听起来像一个坏主意。委托至少需要与其委托的对象一样长，并且您无法控制托管对象的生命周期 - 这由上下文来处理。

正如你在你的问题中提到的那样，错误也可能是一个问题 - 任何状态信息都可能在任何时候消失，再次失控。

此外，这听起来像是一个相当严重的违反MVC，如果这关系到你。

来源

2012-02-11 13:02:34 jrturton

这是如何违反MVC？事实上，观察状态变化是MVC的一个组成部分。什么是KVC？第一段提到了模型更改观察者：https：//developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/KeyValueCoding.html。 – Rob 2013-03-12 02:31:26

你在说KVC吗？我在谈论MVC。他们是两个完全不同的东西。 – jrturton 2013-03-12 07:14:23

我的MVC要点是OP将有效地制作控制器的模型对象部分。 – jrturton 2013-03-12 07:16:23

是否让NSManagedObject成为一个良好的实践？

回答

相关问题