任务详情：

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

因此，我创建了一个实体"hardwareObject"，它代表了该设备的一些属性，例如value1 和 value2.

我创建了一个连接处理程序类，我将其定义为我的"hardwareObject"实体的瞬态属性。在 UI 更改时，核心数据对象被修改，核心数据对象本身告诉它的连接发送 value1 或 value2 的更改。

我想在新数据通过委托方法到达时通知"hardwareObject"的实例，因此它是它的属性的委托。

我想知道是否让 NSManagedObject 成为 s.th 的代表。是个好习惯吗？

这可能会导致故障或其他与核心数据相关的问题出现问题吗？
还是我应该更好地创建一个 sharedInstance 主连接处理程序对象来处理每个连接处理程序并仅在需要时与我的核心数据对象通信？

这是一个完全有效的设计。 NSManagedObjects 可以由它们的(托管对象)上下文管理，但是如果您保留一个 NSManagedObject，它将保持有效，并且您可以自由地在该类中实现任何特殊业务逻辑或使其成为委托。事实上，Core Data 允许您将 NSManagedObject 子类化的原因之一就是您可以做这些事情。

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

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

正如您在问题中提到的那样，故障也可能是一个问题 - 任何状态信息都可能在任何时候消失，再次超出您的控制。

此外，如果您担心的话，这听起来像是对 MVC 的严重违反。