在学习 Core Data 时，我注意到 Apple 如何（在 Xcode 的模板中）直接使用视图控制器中的查询类。这似乎是糟糕的 MVC（直接在视图控制器内部具有数据库访问逻辑）。将这些类型的操作抽象为一组单独的类，从数据库中获取数据并将其传递回调用它的视图控制器是否有意义？
编辑——
所以，为了清楚起见，当我说“各种操作”时，我特别指的是 CRUD 操作。不过，如果您对所谓的“模型控制器”会做的其他事情有想法，我很想听听。
【问题讨论】：
标签： ios cocoa-touch model-view-controller core-data
这是一个见仁见智的问题，通常是的，模板是最简单的工作示例形式。例如，很难让一个模板衍生出多个文件。
是的，就个人而言，我通常会分离出一个单独的 NSManagedObject 子类。我喜欢拥有一个包含所有自动生成的东西的 _MySubclass 对象，然后让模型实际引用具有基于模型的业务逻辑的 MySubclass（如果愿意，您也可以使用 mogenerator 或其他方法来执行此操作）。也许将其视为“模型控制器”和“视图控制器”是另一种说法。
【讨论】：
这是一个非常好的问题，答案可能取决于您的具体情况。也许架构纯粹主义者会坚持使用单独的模型控制器，这种方法有很多好处。但是，有时我发现自己在进行简单视图时会使用键值。当事情变得更复杂时，例如，为 Mac 和 iOS 编写相同的模型时，拥有单独的模型控制器将允许您重用大量代码。当您必须分歧时，Obj C 类别是一种非常简洁的方式来扩展功能而不会增加大量开销。我个人更喜欢类别而不是广泛的子类化。
自从 NSFetchedResultsController 发布以来，我的模型类更精简了。这有很多细微差别，经验将帮助您为您的应用程序提出最佳解决方案。我还发现，预先编写单元测试将帮助您解决问题并验证您的设计，或者将您送回绘图板:)
【讨论】：