为MVCdevise模式组织iOS项目
我正在为iPhone的多视图应用程序工作，目前有我的意见（视图）设置和他们的转换（控制器？）很好地工作。 现在我想为实际的程序数据（MODEL）添加对象。
我的问题是：我应该如何构build我的数据以遵守模型视图控制器（MVC）devise模式？ 我知道我应该创build单独的类来实现我的数据结构，并且我的控制器类可以将消息从视图传递给它们，但是我应该检查其他任何组织考虑因素吗？ 特别是对于cocoa触摸，Xcode或iOS？
其他细节：播放预先录制的和可能用户生成的audio也是必不可less的。 我知道这些是模型元素，但是它们与“V”和“C”究竟有什么关系，我仍然有点模糊。 我想当用户操作需要audio播放时，CONTROLLER应该传递一个消息给MODEL以准备好适当的声音，但是播放的调节到底在哪里？ 在我想象的与ViewController分开的“PlayerController”中？
非常感谢和赦免我的MVC noobery。
迦勒给出了一个很好的介绍和如何思考这个问题的概述。 在你的具体情况下，这里有一些你可能会给你的描述：
-
剪辑（M） – 负责保存实际的audio数据。 它会知道如何解释数据并给出有关它的信息，但它实际上不会发挥任何作用。
-
播放器（V） – 实际上播放音箱上的剪辑。 是的，这是MVC中的一种观点 。 audio只是另一种介绍。 这就是说，你永远不会把它称为“PlayerView”，因为这将表明它是UIView的一个子类。
-
PlayerView（V） – 播放器的屏幕表示。 不知道剪辑。
-
ClipManager（C） – 一个可跟踪系统中所有剪辑并pipe理从networking中获取剪辑的对象，将其添加到caching等。
-
PlayerViewController（C） – 从ClipManager中检索一个剪辑，并协调一个Player和一个PlayerView来显示和播放，以及任何其他UI元素（如“后退button”等）。
这只是一个例子，你可能会打破一些理论的audio播放器应用程序。 有很多正确的MVC方式来做到这一点，但这是一个考虑的方法。
约翰·沃芬勋爵（我确信，在他之前的人）说：“人物就是你在黑暗中。 那么，一个模型就是没人注意的应用程序 – 数据和逻辑定义了应用程序的行为方式，而不pipe它是如何在屏幕上显示的。
想象一下，你决定添加一个命令行界面到你的应用程序。 您仍然希望使用相同的结构来pipe理您的数据，并且基于数据进行sorting，筛选和计算的逻辑也应该是相同的。 无论用户如何看待应用程序或与应用程序进行交互，应用程序中的代码都是重要的/有用的，就是模型。
模型可以非常简单，完全由标准对象组成。 iOS应用程序通常更多地是关于检索，存储和显示数据，而不是关于处理数字，所以有一个模型只是一个字典数组，或者是一个深层次的字典层次结构并不罕见。 如果你看看Core Data的NSManagedObject类，它在许多方面与NSMutableDictionary类似。 所以，如果合适，不要害怕使用标准对象。
也就是说，您当然也可以创build自己的模型对象，如果您有一定的要求来强制执行数据，或者希望能够从数据中获取信息，那么这很有用。
初学者经常想知道每个控制器如何访问模型。 一些人主张使用单例模式，主要是因为它提供了一个单一的，共享的，全局可访问的对象。 我不推荐这个。 相反，应用程序中有一些高级对象，例如应用程序委托创build/加载模型（可能是许多单独对象的graphics），并将模型指针指向需要它的任何视图控制器。 如果这些控制器依次创build其他视图控制器，则他们可以再次向其子控制器提供指向该模型（或其一部分）的指针。
我希望有帮助。