iphone - 在 XCode 中组织 iPhone MVC 代码的标准方法是什么？

Question

我有一个 iPhone 应用程序，其中包含多个 View 及其关联的 Controller 。查看示例代码，我看到了组织这些文件的不同方法 - 要么对所有 View 进行分组，然后对所有 Controller 进行分组，要么按功能对 View 和 Controller 进行分组。

选项 1 - View 和 Controller 单独分组

-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

从 MVC 的角度来看，选项 1 似乎更有意义 - 代码组合在一起，但我想知道随着应用程序增长到 10 多个 View 和 Controller ，这是最合乎逻辑和可维护的吗？是否有关于此的最佳实践建议？目前，我将是唯一维护该应用程序的人，但无论是否有多个开发人员，我都希望尽可能使用最佳实践。有这方面的公开标准吗？

Answer 1

我现在正在开发一个大型 xCode 项目。它不适用于 iPhone，但我认为这对于文件结构布局来说并不重要:)

我从选项 #1 开始，后来当文件数量增加时转向选项 #2。我倾向于按“接口(interface)”对事物进行分组，即与应用程序中特定功能区域相关的所有源，然后根据需要为更大的部分创建子组。

就命名而言，我更喜欢使用尽可能少的类名不动产来标识模型、 View 和 Controller ，因此我的类名看起来类似于:

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