在XCode中組織iPhone MVC代碼的標準方式是什麼？

我有一個iPhone應用程序，其中包含多個視圖及其關聯的控制器。看看示例代碼，我已經看到了組織這些文件的不同方式 - 可以將所有視圖分組，然後將所有控制器分組，或者按功能對視圖和控制器進行分組。在XCode中組織iPhone MVC代碼的標準方式是什麼？

選項1 - 視圖和控制器單獨分組

-Views 
    | 
    - EditItemView.h 
    - EditItemView.m 
    - AddItemView.h 
    - AddItemView.m 

-Controllers 
    | 
    - EditItemViewController.h 
    - EditItemViewController.m 
    - AddItemViewController.h 
    - AddItemViewController.m

選項2 - 按功能分組的項目

-AddItem 
    | 
    - AddItemViewController.h 
    - AddItemViewController.m 
    - AddItemView.h 
    - AddItemView.m 

-EditItem 
    | 
    - EditItemViewController.h 
    - EditItemViewController.m 
    - EditItemView.h 
    - EditItemView.m

選項1似乎更有意義從MVC觀點來看 - 的代碼被分組在一起，但我想知道應用程序增長到10多個視圖和控制器，是最合理和可維護的嗎？圍繞此建議是否有最佳實踐建議？目前，我將是唯一一個維護應用程序的人，但是否會有多個開發人員，我希望儘可能使用最佳實踐。有沒有公布標準呢？

來源

2009-06-04 Tai Squared

我正在處理一個大的xCode項目。它不是iPhone的，但我不認爲這是重要的文件結構佈局:)

我開始與選項＃1，後來轉移到類似選項＃2的東西，當文件的數量增加。我傾向於通過「接口」對所有事物進行分組，即所有與應用程序中的特定功能區域相關的來源，然後根據需要爲更大的部分創建子組。

至於命名推移，我寧願識別模型，視圖和控制器使用盡可能少的類名房地產越好，這樣我的類名類似於：

AM_DillPickle // model class 
AV_Sasquatch // view class 
AC_DirtBike // controller class

這仍然允許快速目視檢查以查看班級的類型（M，V或C），但爲名稱的描述部分留下更多空間。

我也認爲有必要指定不適合MVC模式的一些類（喘氣！）：

AU_Helper  // utility class (text formatting, high-level math, etc.) 
AD_Widget  // device class (used to represent hardware drivers)

無論如何，這是已經更多的信息比你要求的，但我發現命名問題與佈局問題相關，因爲真正的問題是：組織我的代碼用於大型xCode項目的最佳方式是什麼？

希望它有幫助。以下是放在一起時的全貌：

[+] Project 
    [-] Target One 
    [+] Target Two 
     [-] Preferences 
     [-] Login 
     [+] Main Window 
      # MainWindow.XIB 
      # AC_MainWindow.h 
      # AC_MainWindow.m 
      # AC_DisplayScreen.h 
      # AC_DisplayScreen.m 
      [-] Home Screen 
       # HomeScreen.XIB 
       # AC_HomeScreen.h 
       # AC_HomeScreen.m 
       # AV_FancyDisplay.h 
       # AV_FancyDisplay.m 
      [+] Widget Screen 
      [+] Other Screen

來源

2009-06-04 22:49:38

有時最好的做法是做最對你有意義的事情。我個人喜歡通過功能進行分組，但是無論哪種方式，如果您不重視有意義的名稱和重構名稱（當它們不再描述功能時），它可能會變得很難處理。

來源

2009-06-04 22:01:38

我不知道XCode中有一個標準組織，特別是因爲IDE內部的項目組織通常不會轉換爲磁盤上的文件組織。

也就是說，我通常會做類似於您的選項1的事情，因爲沒有更好的理由，它與Rails中的文件夾結構更接近，這是我開始搞亂iPhone時最習慣的。

來源

2009-06-04 22:32:34 mmc

隨着項目的增長，第二種選擇更有意義。

此外，默認的項目有廈門國際銀行文件進入「資源」，但再次作爲一個項目的發展這讓很多更有意義相關的文件移動到一些屏幕或其他的一些功能的邏輯組。舉例來說

一個分組安排是：

3rdParty (for something like regex) 
Utilities (for category additions to classes like UITableViewCell) 
Tab1Classes 
--Screen1 
--Screen2 
Tab2Classes 
Tab3Classes 
Data (for holding plists or other data you may want to load during an app run) 
Resources (still here for random images it makes sense to keep central)

應用程序的委託可以在Utilitites掛出，或者根據課程只是浮所有這些羣體上面。

來源

2009-06-04 23:07:39

凡將通用的UI組件在系統中去嗎？說一個從UIView繼承並在多個屏幕上使用的複選框小部件？ – 2010-02-18 20:48:51

選項2更有意義me.Think一下，當你在編碼，你總是圍繞「意見」及其控制器編輯，選擇2讓你找到最有效的方式將相應的文件。

來源

2009-06-05 02:17:57

請參考以下鏈接。希望能幫助到你！

http://akosma.com/2009/07/28/code-organization-in-xcode-projects/（請注意，在這個環節「結論結構」 - 在這個環節結束）

來源

2014-04-01 13:14:14 Sakthimuthiah

標準的Xcode MVC文件夾結構如下。

CoreData：包含DataModel和Entity類。
擴展：包含一個類（默認蘋果類擴展+項目類的擴展。）
助手：包含第三方類/框架（如SWRevealController）+橋接類（如的OBJ下，在斯威夫特類基於項目）
型號：做一個單獨的類（eg.AppModel - 的NSArray，NSDictionary中，字符串等）保存數據。 Web Service Response解析和存儲數據也在這裏完成。
服務：包含Web服務流程
視圖（例如登錄驗證，HTTP請求/響應。）：包含故事板，LaunchScreen.XIB和視圖類。使一個子文件夾中的細胞 - 包含的UITableViewCell，UICollectionView細胞等
控制器：包含邏輯或代碼有關UI元素（例如的UIButton的參考+點擊動作。）

參見：

https://github.com/futurice/ios-good-practices#common-libraries http://akosma.com/2009/07/28/code-organization-in-xcode-projects/

注意：我提到了AppModel和AppController類（它們是單類，如AppDelegate中）

來源

2015-09-21 06:56:01

在XCode中組織iPhone MVC代碼的標準方式是什麼？

回答

相關問題