我正在开发一个应用程序，该应用程序具有用于不同屏幕的多个视图控制器，整个应用程序是关于显示来自 sqlite db 的数据。
我最初的设计是有一个 db 对象（模型），一个对这个模型有独占访问权的主控制器，而所有其他视图控制器只管理窗口、按钮等的视觉方面。
但是在苹果的 ios 应用程序架构的上下文中，我很难实现如何让主控制器在应用程序的整个生命周期中了解所有其他视图控制器。
到目前为止，我已经想到了 3 种方法： 1 - NSNotificationCenter 并让主控制器观察所有其他控制器？ 2 - 让所有其他人的主控制器代表？虽然我仍然不清楚如何定义一个可委托的（我是否编造了这个词？）协议。也就是说，即使对于没有 setDelegate 方法的对象也是如此。 3 - 将一个 db 对象传递给每个视图控制器。虽然这看起来有点像玩 C 传递状态..
有什么想法吗？ 谢谢！
【问题讨论】：
标签： iphone ios ipad model-view-controller
您的方法可能应该是视图控制器和模型尽可能互不了解的方法。我相信这是一种非常常见的设计模式。您应该拥有代表域中每个逻辑“对象”的模型对象。这些对象可能只是状态。接下来，您可能想要创建一个可以访问您的数据库并可以进行查询的控制器（就像您提到的那样）。这些查询的结果应该用于构建逻辑模型对象（例如 XXPerson）的实例，并将它们交给进行查询的任何人。鉴于此，您应用中的每个视图控制器都应执行以下操作：
请注意，您可以为您的数据库控制器使用单例，但如果您询问大多数优秀的开发人员，单例模式是一个令人讨厌的模式。 :) 相反，您的应用程序确实没有理由不能根据需要创建数据库控制器的实例，将其用于某些查询，然后丢弃它。
当然，在内部，您的数据库控制器类应该对数据库具有单一的静态访问权限，并且可能会同步对写入方法的访问权限，这样您就不会遇到并发问题。
有许多可能的设计方法，但松散耦合的设计方法意味着没有一堆相互依赖，这总是一件好事。让您的模型对象、数据库控制器对象和视图都相互独立。当然，视图控制器是将所有这些独立概念连接到功能产品中的桥梁。
无论如何，这是我的看法。 :)
【讨论】：
听起来您正在寻找作为控制器层一部分的数据访问对象或服务/存储。我认为这是一个好主意，也是其他语言中的一种常见模式，出于某种原因，它在 iOS 应用程序中似乎被广泛忽略了。
为每个视图控制器提供一些对象来管理对数据存储的访问。您可能只想构建该商店的单个实例，但您的控制器不需要知道这一点。就任何单个控制器而言，它都被赋予了一个可用于获取和存储模型对象的对象。
我认为您根本不应该尝试阻止您的视图控制器访问模型对象。而是引入一个服务，这样你的视图控制器就不需要知道如何加载或持久化这些模型对象的细节。如有必要，您可以使用该服务在一个模型和另一个模型之间进行转换，如果您发现需要视图模型或不希望您的视图控制器直接与您保留的任何模型对象一起工作。
我认为像这样的依赖应该是强引用而不是委托，并在通过基于构造函数或基于属性的依赖注入或某些适合您的应用程序的控制容器的反转构造时提供给每个视图控制器.
【讨论】：