为MVC设计模式组织iOS项目
我正在为 iPhone 开发一个多视图应用程序，目前我的视图 (VIEW) 设置完毕，它们的转换 (CONTROLLER?) 运行良好。现在我想为实际程序数据（模型）添加对象。
我的问题是：我应该如何构建数据以遵循模型视图控制器 (MVC) 设计模式？我知道我应该创建单独的类来实现我的数据结构，并且我的控制器类可以从视图向它们传递消息，但是我还应该检查其他组织注意事项吗？尤其是 Cocoa Touch、Xcode 或 iOS 特有的那些？
其他细节：播放预先录制的音频以及用户生成的音频也很重要。我知道这些是模型元素，但它们与“V”和“C”的确切关系如何我仍然有点模糊。我想当用户操作需要音频播放时，控制器应该将消息传递给模型以准备适当的声音，但是播放的调节到底应该在哪里？我想象在与 ViewController 分开的“PlayerController”中？
非常感谢并原谅我的 MVC 新手。
I'm working on a multiview app for iPhone and currently have my views (VIEW) set up and their transitions (CONTROLLER?) working nicely. Now I'd like to add objects for the actual program data (MODEL).
My question is: How should I structure my data to adhere to the Model View Controller (MVC) design pattern? I know I should create separate classes to implement my data structures and that my controller classes can pass messages to them from the view, but are there any other organizational considerations I should examine? Especially those particular to Cocoa Touch, Xcode, or iOS?
Other particulars: Playback of pre-recorded and perhaps user-generated audio will also be essential. I know these are model elements, but how exactly they relate to the "V" and the "C" I'm still a bit fuzzy on. I suppose when a user action requires audio playback, the CONTROLLER should pass a message to the MODEL to ready the appropriate sounds, but where exactly should regulation of the playback live? In a "PlayerController" separate from the ViewController I imagine?
Many thanks and pardon my MVC noobery.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Caleb 对如何思考这个问题给出了很好的介绍和概述。在您的特定情况下，以下是您可能会给出描述的一些部分：
Clip (M) - 负责保存实际的音频数据。它知道如何解释数据并给出有关数据的信息，但它实际上不会播放任何内容。
播放器 (V) - 实际上在扬声器上播放剪辑。是的，这就是 MVC 中的一种视图。音频只是另一种演示。也就是说，您永远不会将其称为“PlayerView”，因为这表明它是 UIView 的子类。
PlayerView (V) - 播放器的屏幕表示。对 Clips 一无所知。
ClipManager (C) - 一个对象，用于跟踪系统中的所有剪辑并管理从网络获取它们、添加和删除它们到缓存等。
PlayerViewController (C) - 从 ClipManager 检索剪辑，并协调 Player 和 PlayerView显示和播放它，以及任何其他 UI 元素（如“后退按钮”等）。
这只是一个示例，说明如何将其分解为某些理论上的音频播放器应用程序。有许多正确的 MVC 方法可以做到这一点，但这只是一种思考方式。
Caleb gives a good introduction and overview of how to think about the problem. In your particular case, here are some of the pieces you would might have given your description:
Clip (M) - Responsible for holding the actual audio data. It would know how to interpret the data and given information about it, but it wouldn't actually play anything.
Player (V) - Actually plays a clip on the speakers. Yes, that's a kind of view in MVC. Audio is just another kind of presentation. That said, you'd never call it "PlayerView" because that would suggest it were a subclass of UIView.
PlayerView (V) - A screen representation of the Player. Knows nothing about Clips.
ClipManager (C) - An object that would keep track of all the clips in the system and manage fetching them from the network, adding and removing them to caches, etc.
PlayerViewController (C) - Retrieves a Clip from the ClipManager, and coordinates a Player and a PlayerView to display and play it, as well as any other UI elements (like a "back button" or the like).
This is just an example of how you might break it down for some theoretical audio player app. There are many correct MVC ways to do it, but this is one way to think about it.
约翰·沃芬勋爵（我确信，在他之前的某个人）说过：“品格就是你在黑暗中的样子。”好吧，模型就是无人查看时应用程序的样子——它是定义应用程序行为方式的数据和逻辑，无论它在屏幕上如何呈现。
想象一下，您决定向应用程序添加命令行界面。您仍然希望使用相同的结构来管理数据，并且基于数据进行排序、筛选和计算的逻辑也应该仍然相同。无论用户如何查看应用程序或与应用程序交互，应用程序中仍然重要/有用的代码就是模型。
模型可以非常简单并且完全由标准对象组成。 iOS 应用程序通常更多地是关于检索、存储和显示数据，而不是处理数字，因此拥有一个仅是字典数组或多个深度的字典层次结构的模型并不罕见。如果您查看 Core Data 的 NSManagedObject 类，您会发现它在许多方面与 NSMutableDictionary 相似。因此，如果合适的话，不要害怕使用标准对象。
也就是说，您当然也可以创建自己的模型对象，如果您有某些想要对数据强制执行的要求，或者您希望能够从数据中获取信息，那么这会很有用。
初学者经常想知道每个控制器如何访问模型。有些人主张为此使用单例模式，主要是因为它提供了一个单一的、共享的、全局可访问的对象。我不推荐这个。相反，在您的应用程序中拥有一些高级对象，例如应用程序委托创建/加载模型（这可能是许多单独对象的图形），并向任何需要它的视图控制器提供指向模型的指针。如果这些控制器依次创建其他视图控制器，它们可以再次向其子控制器提供指向模型（或其一部分）的指针。
我希望这有帮助。
Lord John Worfin (and, I'm sure, someone before him) said: "Character is what you are in the dark." Well, a model is what an application is when nobody is looking -- it's the data and logic that defines how the app behaves regardless of how it's presented on screen.
Imagine that you decide to add a command-line interface to your application. You'd still want to use the same structures for managing your data, and your logic for sorting, sifting, and calculating based on the data should still be the same too. The code in your app that remains important/useful no matter how the user sees or interacts with the app is the model.
A model can be very simple and made up entirely of standard objects. iOS apps are often more about retrieving, storing, and displaying data than they are about crunching numbers, so it's not unusual to have a model that's just an array of dictionaries, or a hierarchy of dictionaries that's several levels deep. If you look at Core Data's NSManagedObject class, it's similar in many respects to NSMutableDictionary. So, don't be afraid to use standard objects if they're appropriate.
That said, you can certainly also create your own model objects, and that's useful if you have certain requirements that you want to enforce on your data, or if you want to be able to derive information from the data.
Beginners often wonder how each controller gets access to the model. Some folks advocate using the singleton pattern for this, mainly because it provides a single, shared, globally accessible object. I don't recommend this. Instead, have some high-level object in your app such as the app delegate create/load the model (which will likely be a graph of many individual objects) and give a pointer to the model to any view controllers that need it. If those controllers in turn create other view controllers, they can again provide a pointer to the model (or part of it) to their child controllers.
I hope that helps.