从多个视图控制器获取和设置核心数据模型的最合适模式是什么？

Question

假设我有一个包含几个实体的核心数据模型，并且在整个应用程序的生命周期中，我将从不同的视图中获取和设置这些实体的属性。

至少对我而言，似乎将托管对象上下文从视图控制器传递到视图控制器，并让控制器的代码知道不同的实体或派生对象反对去耦。事实上，有一个类似的问题，唯一的答案是建议传递托管对象上下文。

所以，根据MVC的精神，我认为视图控制器更有意义坚持控制视图，并且有一个单例模型控制器，通过这些控制器，这些视图控制器可以查询模型以提供其视图并在何时通知需要根据用户与视图的交互来更新模型。

但我不确定如何实现单模型控制器接口。例如，这里有一些想法：

• 使这个控制器成为所有视图控制器的委托和数据源？
• 让控制器只是一个数据源并使用通知进行更新？
• KVC / O 2
• 是一个集中桥从/到模型的整个想法只是过度设计MVC模式？也就是说，是否有一些合理的论据支持传递托管上下文而不被认为是糟糕的面向对象设计？

我想的另一件事是，如果单例控制器是委托和数据源，获取模型数据和更新模型的方法应该实现某种访问者模式，对吧？这意味着，例如，如果视图控制器A允许用户与模型实体/对象A交互，并且某些视图控制器B允许模型对象B相同，并且两个视图控制器都依赖于同一个委托，则委托将必须有一些方法可以知道它应该针对哪个模型实体，具体取决于具体的控制器调用它。

我很感激任何想法/想法

Answer 1

你对“模型控制器”的想法是有道理的，问题是我认为你可能认为它错了。

它不是真正的“模型控制器”，它是模型。在MVC（传统上）中，视图与其控制器进行通信，以获取有关如何处理交互的建议，并且控制器根据其从模型中收集的逻辑和信息决定告诉他们什么。

所以，你只是进一步抽象模型，这是一件好事。 “集中式桥接”的想法是你想要的MVC。您的控制器应该看到底层模型实现的高级抽象，就像所有接口和抽象层一样。

就实施模型而言，我不确定哪种方法是“最佳”，但我无法想象使用委托/数据源策略（或发送）通知控制器）是有害的，我猜这取决于你感到满意。如果你喜欢KVC / KVO，我怀疑它会伤害你。就访客模式而言，有关跟踪哪个控制器应该在模型中的哪个对象的逻辑。

Answer 2

在我看来，你最关心的是从控制器传递模型。控制器参考和使用模型是完全正常的，但是尝试管理它们的创建和渗透，你是对的，有点多。

我建议使用可以为模型生成访问层的依赖注入容器。这样控制器将通过DI传递给它们的模型，而不必传递如何创建模型类。

单一集中式桥接器的想法也不错，但它会让单元测试变得有点棘手。

Answer 3

最后，我最终放弃了单例模式的委托/数据源方法：

我想到了以下内容：

• 所有控制器都与单个共享协作 managedObjectContext
• 核心数据模型本身围绕一个“配置” 实体（不是核心数据文献所指的配置） 到）。
• 此“默认配置”也是所有控制器交互的内容 因为所有其他实体都存在于此的上下文中 配置实体。

基本上，我有一个共享资源，应该以类似于全局变量的方式访问。

所以我将共享资源封装在Singleton中，所有其他控制器都可以通过其接口查询和修改模型，而不需要了解内部结构。

通用界面允许以下内容：

• [ModelControllerBridge sharedBridge] defaultConfiguration] 返回默认的共享NSManagedObject
• [[ModelControllerBridge sharedBridge] newDataSample]返回一个 新的NSManagedObject并在内部分配并插入它 模型中的适当实体。
• [[ModelControllerBridge] shouldCommitChangesToModel]发出信号 上下文应该提交给永久存储
• 等