4

我使用 Core Data 已经有一段时间了,但我只是问了自己一个问题,我自己总是倾向于创建某种本地存储类来管理 Core Data 模型,这将是一个有参考的单例类对于托管对象上下文,我有创建新托管对象、删除对象、保存等的方法……而且我的托管对象子类实际上只是模型。

但我也经常与其他人的项目一起工作,有时其他开发人员倾向于以类方法的形式向托管对象子类添加更多逻辑,并且有一个非常简单或有时根本没有核心数据“包装器”类。

例如,我通常会这样做:

User *me = [[MyDataStore getInstance] createUserWithName:@"Daniel"];

而其他宁愿有:

User *me = [User userWithName:@"Daniel"];

显然后者更好,并且在我看来更人性化,但最终可能会产生很多零散的代码,但另一方面,我的解决方案意味着你有一个非常大的文件,一旦它通过一定的长度。

我想知道其他人是否可以分享他们对此的看法。谢谢。

4

1 回答 1

4

从 MVC 的角度来看,将逻辑代码放在 NSManagedObject 子类中是更正确的做法。就个人而言,我觉得这样做更合乎逻辑,即这段代码创建了一个新的 User 实例,所以我将它放在 User 类中。

在实践层面上,我曾经讨厌将逻辑代码放在我的 NSManagedObject 子类中,因为如果我修改了我的模型,它会全部消失,但是我现在使用MoGenerator来处理所有这些,我不必担心我的自定义逻辑被覆盖。

最近我倾向于尝试和利用 CoreData 的另一件事是抽象实体。它们不仅非常适合简化您的模型,还可以简化您的自定义逻辑,我的意思是它基本上只是围绕 CoreData 进行子类化。

只是我的意见和目前对我有用的方法,希望它对某人有所帮助,期待任何其他贡献!

于 2012-07-18T04:22:59.917 回答