一个典型的 iOS 应用程序是使用 MVC 模式开发的。如果我有额外的包含纯逻辑的类,比如
- 花式算法(AES)
- 简单的钥匙串访问(内置 C 函数的包装器)
- 连接到套接字或 HTTP 请求
- 好吧,也许任何东西都是图书馆,与 UI 无关
这些类既不是控制器,也不是模型,也不是视图。他们提供功能性服务。他们如何适应这个 MVC 的东西?
一个典型的 iOS 应用程序是使用 MVC 模式开发的。如果我有额外的包含纯逻辑的类,比如
这些类既不是控制器,也不是模型,也不是视图。他们提供功能性服务。他们如何适应这个 MVC 的东西?
这些库/类是控制器的一部分,因为它使用它们来实现其功能。
例如,控制器连接到网络服务器并显示到视图,这是控制器工作的一部分,或者在将某些数据发送到模型之前使用一些库加密一些数据。
这三个类别(模型、视图、控制器)中的任何一个都可以自由使用可能不严格适合其中一个角色的其他类。
例如,模型对象可能使用 AES 加密和解密存储的数据,并且它可能将加密密钥存储在钥匙串中。控制器可能会使用钥匙串来限制对应用程序某些部分的访问。视图可能会使用一个实现 FFT 的类来帮助它对数据进行分区以进行显示。
MVC 是设计应用程序的范例,但它并不是允许的类的完整列表。Cocoa 和 Cocoa Touch 本身充满了模型、视图和/或控制器类可能使用的类,但它们本身并不适合这些角色。考虑所有容器类(NSArray、NSSet、NSDictionary 等)、值类(NSNumber、NSString 等)、代表操作系统不同部分的类(NSFileManager、NSUserDefaults 以及其他我不会尝试的东西)分类如 UITouch、NSEvent、NSJSONSerialization 等等。我没有数过,但我猜不适合三个 MVC 角色之一的 Cocoa 和 Cocoa Touch 类远远多于那些。
如果它们是辅助类,那么正如其他人所指出的那样,它们是 MVC 中 C 的一部分。
当然,除非它们是模型的一部分。如果它们为应用程序的数据或业务需求建模,那么它们就是 MVC 中 M 的一部分。
无论如何,在您的控制器内部,您只需使用 import 语句并根据需要使用类。您将实例化类、调用实例方法、调用类方法、将实例存储为属性等。
很多时候,您会发现自己使用类似于[NSUserDefaults standardUserDefaults]
.
由于所有这些类都在执行操作,因此可以将它们视为 Helper 方法或实用程序方法。正如 Antonio MG 所指出的,无论您如何称呼它们,它们仍然是控制器。
例如,我的类中通常有以下控制器:
我将它们标记为控制器,并将它们放在我的 Xcode 项目中的控制器文件夹中。