ios/xcode：核心数据属性和方法的最佳位置
ios/xcode: Best place for Core Data properties and methods
我遵循了各种核心数据教程，它们似乎都推荐了放置核心数据代码的不同位置，即 nsmanagedobject、nsmanagedobjectcotext 和 nspersistent 存储协调器的属性和方法。
在 Xcode 示例项目中，他们将其放在应用程序委托中。
基于 MVC 模式，其他人建议将所有数据和逻辑放在单独的数据中 class，如模型或项目。但是，如果您使用编辑器为数据模型中的每个实体或 table 自动生成 class，这似乎不可取，因为每次这样做都会覆盖核心数据属性和方法
我看到的另一种选择是将它放在视图控制器中。但这似乎不是MVC的一个很好的例子。
当然必须有一个最佳实践。我正在构建应用程序并且不想重做这一重要步骤，因此非常感谢关于这一点的指导。
谢谢。
将逻辑放入 Model class，例如 NSManagedObjectContext 和 NSPersistentStoreCcoordinator 的方法。这个class可以继承自NSObject。
为 NSManagedObjects 创建（如果需要）classes。我的建议是在您的实体 classes 之外保留尽可能多的逻辑。将逻辑添加到实体 class 以对属性值（或更改）做出反应是很诱人的。但是在评估这种方法时，请考虑您的 NSManagedObject 是相当短暂的。不要在您的应用程序内部传递它。 NSManagedObject 可以变成错误，您的逻辑将不再可访问。
考虑将逻辑移至不继承自 NSManagedObject 的单独 class。这可能是您的 Model class。在 Model class 中执行所需的逻辑。 class 不会怪你，你将有更多的自由与上下文。
然后：不要让 Xcode 重新创建您的 class 文件。对模型进行更改后，手动更新 NSManagedObject class 文件。仅当属性的类型或名称更改时才需要更新 class 文件。
此手动过程确实需要一些纪律，但比模型的任何类别或扩展更容易维护和管理 class。
听起来你混淆了一些不同的东西。
Xcode 的项目模板将处理 NSPersistentStoreCoordinator 和 NSManagedObjectContext 的代码放入应用程序委托中。这并不可怕，但也不是很好，许多其他示例建议将它放在其他地方——例如，某种核心数据管理器 class.
该代码不处理 NSManagedObject 实例的属性或自定义方法。这些通常会进入 NSManagedObject 的子 classes。如果您使用 Xcode 生成这些子 classes，您是对的，如果您重做该过程，Xcode 将丢失现有代码。它很方便但很脆弱。更好的方法是使用 mogenerator，一种用于生成子classes 的开源工具。它为每个实体创建两个 subclasses。您将自定义代码放在一个中，而另一个单独放置。如果您重新生成文件，带有自定义代码的文件不会被覆盖。
对整个逻辑使用一个 Model class 是一个糟糕的主意，因为它很快就会变成 God Object.
您可以在 NSManagedObject subclasses 的类别中添加其他方法，这样它们在重新生成 classes 后不会被覆盖。这适用于简单的任务，比如验证数据（在 NSManagedObject 中甚至有用于该目的的内置方法），或者简单的对多关系的过滤（比如在 [= 中获取上周的事件） 13=]实体）。毕竟NSManagedObjects是对象，对象不仅可以存储数据，还可以做事。我已经成功地将这种方法用于具有约 50 个实体的应用程序。
对于更复杂的任务，您可以创建普通的 NSObject subclasses 来处理托管对象。例如，在我的应用程序中，我使用 MessageSynchronizer class 来处理 Message 实体实例，负责与 Web 服务同步消息（它没有访问网络，只是处理可能的本地和远程数据之间的冲突）。对于与显示数据相关的任务（如格式化日期），您可以使用 Model-View-ViewModel pattern and do them in ViewModels. Just remember about essential OOP principles, like Single Responsibility Principle。
我遵循了各种核心数据教程，它们似乎都推荐了放置核心数据代码的不同位置，即 nsmanagedobject、nsmanagedobjectcotext 和 nspersistent 存储协调器的属性和方法。
在 Xcode 示例项目中，他们将其放在应用程序委托中。
基于 MVC 模式，其他人建议将所有数据和逻辑放在单独的数据中 class，如模型或项目。但是，如果您使用编辑器为数据模型中的每个实体或 table 自动生成 class，这似乎不可取，因为每次这样做都会覆盖核心数据属性和方法
我看到的另一种选择是将它放在视图控制器中。但这似乎不是MVC的一个很好的例子。
当然必须有一个最佳实践。我正在构建应用程序并且不想重做这一重要步骤，因此非常感谢关于这一点的指导。
谢谢。
将逻辑放入 Model class，例如 NSManagedObjectContext 和 NSPersistentStoreCcoordinator 的方法。这个class可以继承自NSObject。
为 NSManagedObjects 创建（如果需要）classes。我的建议是在您的实体 classes 之外保留尽可能多的逻辑。将逻辑添加到实体 class 以对属性值（或更改）做出反应是很诱人的。但是在评估这种方法时，请考虑您的 NSManagedObject 是相当短暂的。不要在您的应用程序内部传递它。 NSManagedObject 可以变成错误，您的逻辑将不再可访问。
考虑将逻辑移至不继承自 NSManagedObject 的单独 class。这可能是您的 Model class。在 Model class 中执行所需的逻辑。 class 不会怪你，你将有更多的自由与上下文。
然后：不要让 Xcode 重新创建您的 class 文件。对模型进行更改后，手动更新 NSManagedObject class 文件。仅当属性的类型或名称更改时才需要更新 class 文件。
此手动过程确实需要一些纪律，但比模型的任何类别或扩展更容易维护和管理 class。
听起来你混淆了一些不同的东西。
Xcode 的项目模板将处理 NSPersistentStoreCoordinator 和 NSManagedObjectContext 的代码放入应用程序委托中。这并不可怕，但也不是很好，许多其他示例建议将它放在其他地方——例如，某种核心数据管理器 class.
该代码不处理 NSManagedObject 实例的属性或自定义方法。这些通常会进入 NSManagedObject 的子 classes。如果您使用 Xcode 生成这些子 classes，您是对的，如果您重做该过程，Xcode 将丢失现有代码。它很方便但很脆弱。更好的方法是使用 mogenerator，一种用于生成子classes 的开源工具。它为每个实体创建两个 subclasses。您将自定义代码放在一个中，而另一个单独放置。如果您重新生成文件，带有自定义代码的文件不会被覆盖。
对整个逻辑使用一个 Model class 是一个糟糕的主意，因为它很快就会变成 God Object.
您可以在 NSManagedObject subclasses 的类别中添加其他方法，这样它们在重新生成 classes 后不会被覆盖。这适用于简单的任务，比如验证数据（在 NSManagedObject 中甚至有用于该目的的内置方法），或者简单的对多关系的过滤（比如在 [= 中获取上周的事件） 13=]实体）。毕竟NSManagedObjects是对象，对象不仅可以存储数据，还可以做事。我已经成功地将这种方法用于具有约 50 个实体的应用程序。
对于更复杂的任务，您可以创建普通的 NSObject subclasses 来处理托管对象。例如，在我的应用程序中，我使用 MessageSynchronizer class 来处理 Message 实体实例，负责与 Web 服务同步消息（它没有访问网络，只是处理可能的本地和远程数据之间的冲突）。对于与显示数据相关的任务（如格式化日期），您可以使用 Model-View-ViewModel pattern and do them in ViewModels. Just remember about essential OOP principles, like Single Responsibility Principle。