我正在爲iPhone的多視圖應用程序工作，目前我的視圖（VIEW）設置和它們的轉換（CONTROLLER？）很好地工作。現在我想爲實際的程序數據（MODEL）添加對象。爲MVC設計模式組織iOS項目
我的問題是：我應該如何構建我的數據以遵守模型視圖控制器（MVC）設計模式？我知道我應該創建單獨的類來實現我的數據結構，並且我的控制器類可以從視圖向它們傳遞消息，但是我應該檢查其他任何組織考慮因素嗎？特別是那些特別是可可觸摸，Xcode或iOS？
其他詳情：播放預先錄製的或可能由用戶生成的音頻也是必不可少的。我知道這些都是模型元素，但它們與「V」和「C」的關係究竟有多模糊。我想當用戶操作需要音頻播放時，CONTROLLER應該向MODEL傳遞一條消息以準備好適當的聲音，但播放的規則應該在哪裏生活？在我想象的與ViewController分開的「PlayerController」中？
非常感謝和赦免我的MVC noobery。
Caleb給出了一個很好的介紹和概述如何思考問題。你的具體情況，這裏有一些你可能已經向您介紹了件：
夾（M） - 負責保存實際的音頻數據。它會知道如何解釋數據並提供關於它的信息，但它實際上不會發揮任何作用。
玩家（V） - 實際上是在揚聲器上播放剪輯。是的，這是MVC中的一種視圖。音頻只是另一種演示。也就是說，你永遠不會把它稱爲「PlayerView」，因爲這會表明它是UIView的子類。 PlayerView（V） - 播放器的屏幕表示。對剪輯一無所知。
ClipManager（C） - 一個對象，將保留在系統中的所有剪輯的跟蹤和管理，從網絡獲取它們，添加和刪除他們對緩存等。
PlayerViewController（C） - 從ClipManager中檢索剪輯，並協調Player和PlayerView以顯示和播放它以及任何其他UI元素（如「後退按鈕」等）。
這只是一個例子，你可能會打破一些理論的音頻播放器應用程序。有很多正確的MVC方法可以做到這一點，但這是考慮它的一種方法。
優秀的細分。我認爲這只是涵蓋了應用音頻播放器部分的組織。 ClipManager可能很方便，我還沒有把它想象成一個單獨的組件。非常感謝。 – 2011-03-08 04:32:38
ClipManager應該是控制器還是應該成爲模型的一部分？據我瞭解，該模型不僅僅是應用程序訪問它的原始數據，還包括獨立於用戶界面的核心應用程序行爲。正如@Caleb所定義的，模型既是數據*又是邏輯。 – Danra 2012-03-05 12:55:03
ClipManager是我傾向於稱之爲「模型控制器」，以區別於「視圖控制器」。將模型控制器視爲您建議的更大「模型」的一部分時，通常最有幫助和準確。但在模型中，將「數據」和「控制器」（「管理者」）分開考慮是有益的。讓你的數據太聰明是一個常見的設計問題。所以長話短說，你是對的，但我不會僅僅將ClipManager標記爲「模型」而沒有解釋。 – 2012-03-05 14:38:15
約翰沃芬勳爵（我確信，有人在他面前）說：「人物就是你在黑暗中。」那麼，模型就是沒有人注視時的應用程序 - 數據和邏輯定義了應用程序的行爲方式，而不管它是如何在屏幕上呈現的。
想象一下，您決定爲您的應用程序添加一個命令行界面。您仍然希望使用相同的結構來管理您的數據，並且基於數據進行排序，篩選和計算的邏輯也應該是相同的。無論用戶看到應用程序或與應用程序交互的方式，應用程序中的代碼仍然很重要/有用，這就是模型。
模型可以非常簡單，完全由標準對象組成。 iOS應用程序通常更多地是關於檢索，存儲和顯示數據，而不是關於處理數字的問題，所以有一個模型只是一個字典數組，或者是一個深層次的字典層次結構並不罕見。如果你看看Core Data的NSManagedObject類，它在許多方面與NSMutableDictionary類似。所以，如果它們合適，不要害怕使用標準對象。也就是說，您當然也可以創建自己的模型對象，如果您有一定的要求需要強制執行數據，或者希望能夠從數據中獲取信息，那麼這很有用。
初學者經常想知道每個控制器如何訪問模型。有些人主張爲此使用單例模式，主要是因爲它提供了一個單獨的，共享的，全局可訪問的對象。我不推薦這個。相反，在你的應用程序中有一些高級對象，例如應用程序委託創建/加載模型（這可能是許多單獨對象的圖形），並將模型指針提供給需要它的任何視圖控制器。如果這些控制器依次創建其他視圖控制器，則他們可以再次向其子控制器提供指向該模型（或其一部分）的指針。
我希望有幫助。
控制器並不是關於視圖之間的轉換，而是關於如何管理視圖的實際操作。 – Caleb 2011-03-08 03:25:01