我的应用程序中有几个数据 Controller 。每个数据控制者负责管理数据的某一部分。他们可以访问 CoreData，处理 NSManagedObject，并通过使用 NSManagedObjectContextNSMainQueueConcurrencyType 或 NSPrivateQueueConcurrencyType 队列来确保所有操作都是线程安全的。/code>s 取决于调用者使用数据 Controller 的线程。
它的架构方式只有数据 Controller 知道 CoreData 的内容，例如上下文、托管对象、获取请求等。
这意味着数据 Controller 不应返回NSManagedObject。首先确保它们只能由正确的上下文访问，该上下文仅在数据 Controller 本身中可用，其次是强制实现只有数据 Controller 才能处理与 CoreData 相关的任何内容的架构。
但是数据 Controller 应该返回什么？创建 NSManagedObject 的 NSObject 副本，复制所有属性并返回它是个好主意吗？这是有道理的，但在我看来，这不是理想的解决方案，甚至没有必要。
有更好的方法吗？
最佳答案
在我看来，您已经在问题中给出了正确的答案:
It’s architected in a way that only the data controllers know about CoreData stuff like contexts, managed objects, fetch requests etc.
您应该避免通过向程序的其余部分提供 NSManagedObjects 来破坏与核心数据无关的设计。独立于第三方框架——尤其是持久性框架，是一个很好的、高度可测试的设计。因此，请使用NSObject。
另请记住，持久性框架可能会在程序的生命周期内发生变化。商业模式确实如此。
评论更新
要将 NSManagedObject 转换为 NSObject，反之亦然，您必须编写自己的编码器/转换器类。有很多教程如何将 NSManagedObject 转换为 NSDictionary，包括。关系。
如果确实需要故障，您也必须自己进行。但是，作为一般的性能优化，这应该是您列表中的最后一个主题，并且仅当您在生产中遇到性能问题时才会出现在您的列表中。
关于objective-c - 数据 Controller 是否应该返回 N 个对象的 NSManagedObject，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29717975/