我读了很多关于这个问题的话题,但是没有找到一个合适的答案。我想在没有上下文的情况下创建NSManagedObject的实例。
原因如下:app从服务器获取soap答案。这个答案必须保存到核心数据中。答案看起来像一棵树。
我的想法是覆盖每个实体的init,以便获取数据。之后我将能够创建根实体,根实体的创建将调用另一个实体的创建等等。
应用程序中负责发出请求的部分是通过泛型实现的。有描述每个响应类必须具有的init的协议,例如:

public protocol Parsable {
    init(data: Data)
}

所以你可以看到这里没有上下文的空间。相反,我想创建所有这些实体并一次性将其保存到上下文中。
这里的另一种解决方案是创建重复的类,用响应填充它,然后将其复制到我的核心数据实体中。但这是不必要的重复,我想避免。
任何想法都将受到赞赏。

最佳答案

实际上,“这里的替代解决方案是创建重复的类”是唯一好的解决方案,原因有很多。
在您的例子中,似乎已经有两个这样的对象代表同一个实体。我假设您从服务器接收到的是解析成字典的JSON。这是一个表示同一实体的对象。因此,要将其转换为核心数据,您已经有一个从字典到核心数据管理对象的映射器。
假设托管对象适合直接在应用程序的更高级别中使用是错误的。我们用包装纸包装。因此,您需要一个处理所有数据传输的类,然后让所有接口在任何模块和任何线程上使用数据。这就是为什么您需要将所有数据传输到可能包装托管对象的新类。
因此,假设您有一个名为MyObject的类和一个核心数据类MyObjectEntity并且可能有一个API字典。那么MyObject的接口将是:

init(entity: MyObjectEntity) // Wraps the entity and copies all fields to this class
init(descriptor: [String: Any]) // Copies all fields to this class
var descriptor: [String: Any] // Returns a dictionary ready to be parsed to JSON
func writeToManagedObject() // Will copy all the data to managed object. If the object exists it will modify it, if not it will create a new one. This will not save the database.

通过一些子类化和一些扩展,即使您有许多需要映射的模型,您也可以用它创建一个非常好的系统。而且由于这个类对从任何线程访问和/或保存上下文完全不敏感,所以它可以进行任何其他高级操作。据我所知,你甚至可以用它作为MVVM。

10-07 19:51
查看更多