假设我有一个包含几个实体的核心数据模型，并且在整个应用程序的生命周期中，我将从不同的 View 获取和设置这些实体的属性。
至少对我来说，将托管对象上下文从 View Controller 传递到 View Controller 并让 Controller 的代码了解不同的实体或派生对象似乎不利于解耦。事实上，有一个类似的问题，唯一的答案是绕过托管对象上下文。
因此，本着 MVC 的精神，我认为 View Controller 坚持控制 View 并拥有一个单例模型 Controller 可能更有意义，这些 View Controller 可以通过它查询模型以提供它们的 View 并在何时通知模型需要根据用户与 View 的交互进行更新。
但我不确定如何着手实现单一模型 Controller 接口(interface)。例如，这里有一些想法:
- 让这个 Controller 既是所有 View Controller 的委托(delegate)又是数据源？
- Controller 是否只是一个数据源并使用更新通知？
- kvc/o?
- 从/到模型的集中式桥梁的整个想法是否只是过度设计了 MVC 模式？也就是说，是否有一些合理的论点支持传递托管上下文，而这不会被认为是蹩脚的面向对象设计？
我在想的另一件事是，如果单例 Controller 是委托(delegate)和数据源，那么获取模型数据和更新模型的方法应该实现某种访问者模式，对吗？意思是，例如，如果 View Controller A 允许用户与模型实体/对象 A 交互，而某些 View Controller B 允许模型对象 B 进行相同的交互，并且两个 View Controller 都依赖于同一个委托(delegate)，则委托(delegate)将必须有一些方法可以根据调用它的具体 Controller 来知道它应该针对哪个模型实体。
我会很感激任何想法/想法
最佳答案
您对“模型 Controller ”的想法很有道理，问题是我认为您可能想错了。
它不是真正的“模型 Controller ”，它是模型。在 MVC 中(传统上)， View 与它们的 Controller 通信以获取有关如何处理交互的建议，而 Controller 根据它从模型收集的逻辑和信息来决定告诉它们什么。
实际上，您只是进一步抽象模型，这是一件好事。 “集中桥”的想法是您在 MVC 中想要的。与所有接口(interface)和抽象层一样，您的 Controller 应该看到底层模型实现的高级抽象。
就实现模型而言，我不确定哪种是“最佳”方法，但我无法想象使用委托(delegate)/数据源策略(或发送通知 Controller )将是有害的，我想这取决于你对什么感到满意。如果您喜欢 KVC/KVO，我怀疑它会伤害您。就访问者模式而言，关于跟踪哪个 Controller 获取哪个对象的逻辑应该在模型中。
关于ios - 从多个 View Controller 获取和设置核心数据模型的最合适模式是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9525748/