Cocoa touch 为MVC设计模式组织iOS项目

我正在为iPhone开发一个多视图应用程序，目前已经设置了我的视图（VIEW），并且它们的转换（CONTROLLER？）运行良好。现在我想为实际的程序数据（模型）添加对象

我的问题是：我应该如何构造数据以遵循模型-视图-控制器（MVC）设计模式？我知道我应该创建单独的类来实现我的数据结构，并且我的控制器类可以从视图向它们传递消息，但是我还应该检查其他组织方面的注意事项吗？特别是Cocoa Touch、Xcode或iOS特有的

其他详情：播放预先录制的音频，可能还有用户生成的音频也很重要。我知道这些是模型元素，但它们与“V”和“C”的确切关系我还是有点模糊。我想，当用户操作需要音频回放时，控制器应该向模型传递一条消息，以准备好合适的声音，但是回放的调节应该在哪里进行呢？在一个与我想象中的ViewController分离的“PlayerController”中

非常感谢并原谅我的MVC noobery。

约翰·沃芬勋爵（我相信，他之前的某个人）说：“角色就是你在黑暗中的样子。”好吧，模型就是应用程序在无人关注时的样子——数据和逻辑决定了应用程序的行为，而不管它在屏幕上如何显示

假设您决定向应用程序添加命令行界面。您仍然希望使用相同的结构来管理数据，并且基于数据进行排序、筛选和计算的逻辑也应该相同。无论用户如何看待应用程序或与应用程序交互，应用程序中仍然重要/有用的代码就是模型

模型可以非常简单，完全由标准对象组成。iOS应用程序通常更多的是检索、存储和显示数据，而不是处理数字，因此，拥有一个仅仅是一组字典的模型，或者一个有几个层次的字典层次结构，这并不罕见。如果您查看核心数据的NSManagedObject类，它在许多方面与NSMutableDictionary类似。所以，如果合适的话，不要害怕使用标准对象

也就是说，您当然也可以创建自己的模型对象，如果您希望对数据强制执行某些要求，或者如果您希望能够从数据中派生信息，这将非常有用

初学者经常想知道每个控制器是如何访问模型的。有些人主张为此使用单例模式，主要是因为它提供了一个单一的、共享的、全局可访问的对象。我不推荐这个。相反，在应用程序中使用一些高级对象，例如应用程序代理创建/加载模型（可能是许多单独对象的图形），并向需要它的任何视图控制器提供指向模型的指针。如果这些控制器依次创建其他视图控制器，则它们可以再次向其子控制器提供指向模型（或模型的一部分）的指针

---

我希望这能有所帮助。

Caleb很好地介绍了如何思考这个问题。在您的特定案例中，以下是您可能会给出描述的一些片段：

• 剪辑（M）-负责保存实际音频数据。它将知道如何解释数据并提供有关数据的信息，但实际上它不会播放任何内容

• 播放器（V）-实际在扬声器上播放剪辑。是的，这是MVC中的一种视图。音频只是另一种演示。也就是说，您永远不会称它为“PlayerView”，因为这意味着它是UIView的一个子类

• PlayerView（V）-玩家的屏幕表示。对剪辑一无所知

• ClipManager（C）-一个对象，用于跟踪系统中的所有剪辑，并管理从网络中获取剪辑、将剪辑添加到缓存或将其删除等

• PlayerViewController（C）-从ClipManager检索剪辑，并协调播放器和PlayerView以显示和播放它，以及任何其他UI元素（如“后退按钮”等）

---

这只是一个例子，你可以把它分解成一些理论上的音频播放器应用程序。有许多正确的MVC方法可以做到这一点，但这是一种思考方法。

控制器与其说是视图之间的转换，不如说是管理视图的实际功能。非常好。我认为这几乎涵盖了应用程序音频播放器部分的组织。ClipManager可能很方便，我还没有想到它是一个单独的组件。非常感谢。ClipManager应该是控制器还是模型的一部分？据我所知，该模型不仅涉及应用程序访问的原始数据，还涉及独立于用户界面的核心应用程序行为。正如@Caleb所定义的，模型既是数据又是逻辑。ClipManager是我倾向于称之为“模型控制器”的东西，以将其与“视图控制器”区分开来。通常，将模型控制器视为您所建议的更大“模型”的一部分是最有帮助和准确的。但在模型中，将“数据”和“控制器”（“管理者”）视为独立的是很有用的。使数据过于智能化是一个常见的设计问题。长话短说，您是对的，但我不会不加解释就将ClipManager标记为“模型”。