Question

我有一个包含多个视图及其相关控制器的iPhone应用程序。查看示例代码，我看到了组织这些文件的不同方法 - 将所有视图分组，然后将所有控制器分组，或按功能对视图和控制器进行分组。

选项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

从MVC的角度来看，选项1似乎更有意义 - 代码组合在一起，但我想知道随着应用程序增长到10多个视图和控制器，这是最合乎逻辑和可维护的吗？围绕这个是否有最佳实践建议？目前，我将是唯一一个维护应用程序的人，但不管是否会有多个开发人员，我希望尽可能多地使用最佳实践。是否有关于此的公布标准？

Answer 1

我正在研究一个大型的xCode项目。它不适用于iPhone，但我不认为这对文件结构布局很重要：）

我从选项＃1开始，后来在文件数量增加时转移到选项＃2。我倾向于通过“接口”对事物进行分组，即，与应用程序内特定功能区域相关联的所有源，然后在需要时为更大的部分创建子组。

就命名而言，我更喜欢使用尽可能少的类名称来识别模型，视图和控制器，因此我的类名看起来类似于：

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

这仍然允许快速目视检查以查看类的类型（M，V或C），但它为名称的描述部分留出了更多空间。

我还发现指定一些不适合MVC模式的类很有用（ gasp ！）：

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

Answer 2

随着项目的增长，第二种选择更有意义。

此外，默认项目有xib文件进入“资源”但是随着项目的增长，将相关文件移动到某个屏幕或其他功能的逻辑组中会更有意义。

作为例子的一种分组安排是：

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)

App代理可以在Utilitites中闲逛，也可以只悬浮在Classes下的所有群组之上。

Answer 3

有时最好的做法是做对你最有意义的事情。我个人喜欢通过功能进行分组，但无论哪种方式，如果您不再考虑有意义的名称并在不再描述功能时重构名称，它就会变得难以处理。

Answer 4

我不知道XCode中有一个标准组织，特别是因为IDE中的项目组织通常不会转换为磁盘上的文件组织。

也就是说，我通常会做类似于你的选项1的事情，因为没有更好的理由比Rails中的文件夹结构更接近，这是我开始搞乱iPhone时最习惯的。

Answer 5

标准的Xcode MVC文件夹结构如下。

CoreData：包含DataModel和实体类。
扩展：包含一个类（默认的apple类扩展+项目类扩展。）
Helper：包含第三方类/框架（例如SWRevealController）+桥接类（例如基于Swift的项目中的Obj C类）
模型：创建一个单例类（例如，AppModel - NSArray，NSDictionary，String等）来保存数据。解决和存储数据的Web服务响应也在这里完成。
服务：包含Web服务流程（例如，登录验证，HTTP请求/响应）
查看：包含故事板，LaunchScreen.XIB和视图类。创建子文件夹单元格 - 包含UitableviewCell，UICollectionView Cell等。
控制器：包含与UIElements相关的逻辑或代码（例如UIButton的参考+点击动作）

参考：

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

注意：我已经提到了AppModel和AppController类（它们是像AppDelegate这样的单例类）

Answer 6

选项2对我来说更有意义。想想看，在编码时，你总是在“视图”及其控制器周围编辑，选项2让你以最有效的方式找到合适的文件。

Answer 7

请参阅以下链接。希望它有所帮助！

http://akosma.com/2009/07/28/code-organization-in-xcode-projects/（请注意此链接中的“结论结构” - 在此链接的末尾）

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

7 个答案: