在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代码的标准方式是什么？

回答

相关问题