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