在 XCode 中组织 iPhone MVC 代码的标准方法是什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/953127/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the standard way to organize iPhone MVC code in XCode?
提问by Tai Squared
I have an iPhone application that contains several views and their associated controllers. Looking at sample code, I've seen different different ways to organize these files - either have all of the views grouped, then all of the controllers grouped, or group the views and controllers by functionality.
我有一个 iPhone 应用程序，其中包含多个视图及其关联的控制器。查看示例代码，我看到了组织这些文件的不同方法 - 将所有视图分组，然后将所有控制器分组，或者按功能对视图和控制器进行分组。
Option 1 - Views and controllers grouped separately
选项 1 - 视图和控制器分开分组
-Views
|
- EditItemView.h
- EditItemView.m
- AddItemView.h
- AddItemView.m
-Controllers
|
- EditItemViewController.h
- EditItemViewController.m
- AddItemViewController.h
- AddItemViewController.m
Option 2 - Items grouped by functionality
选项 2 - 按功能分组的项目
-AddItem
|
- AddItemViewController.h
- AddItemViewController.m
- AddItemView.h
- AddItemView.m
-EditItem
|
- EditItemViewController.h
- EditItemViewController.m
- EditItemView.h
- EditItemView.m
Option 1 seems to make more sense from a MVC standpoint - the code is grouped together, but I'm wondering as the app grows to 10+ views and controllers, is that the most logical and maintainable? Is there a best practice recommendation around this? Currently, I will be the only one maintaining the app, but whether or not there will be multiple developers, I want to use best practices as much as possible. Are there published standards on this?
从 MVC 的角度来看，选项 1 似乎更有意义 - 代码组合在一起，但我想知道随着应用程序增长到 10 多个视图和控制器，这是最合乎逻辑和可维护的吗？是否有关于此的最佳实践建议？目前，我将是唯一一个维护应用程序的人，但无论是否有多个开发人员，我都希望尽可能多地使用最佳实践。有这方面的公开标准吗？
回答by e.James
I'm working on a big xCode project right now. It isn't for the iPhone, but I don't think that matters for the sake of file structure layout :)
我现在正在做一个大型的 xCode 项目。它不适用于 iPhone，但我认为这对于文件结构布局来说并不重要:)
I started out with option #1 and later moved to something like option #2 when the number of files increased. I tend to group things by "interfaces" i.e., all of the sources associated with a particular area of functionality within the application, and then create sub-groups for larger sections if need be.
我从选项 #1 开始，后来当文件数量增加时转向选项 #2。我倾向于通过“接口”对事物进行分组，即与应用程序中特定功能区域相关的所有源，然后在需要时为更大的部分创建子组。
As far as naming goes, I prefer to identify Model, View and Controller using as little class name real-estate as possible, so my class names look similar to:
就命名而言，我更喜欢使用尽可能少的类名来标识模型、视图和控制器，因此我的类名看起来类似于：
AM_DillPickle // model class
AV_Sasquatch // view class
AC_DirtBike // controller class
This still allows for a quick visual check to see the type of a class (M, V, or C) but it leaves more room for the descriptive part of the name.
这仍然允许快速视觉检查以查看类的类型（M、V 或 C），但它为名称的描述部分留下了更多空间。
I've also found it useful to specify some classes that do not fit into the MVC pattern (gasp!):
我还发现指定一些不适合 MVC 模式的类很有用（喘气！）：
AU_Helper // utility class (text formatting, high-level math, etc.)
AD_Widget // device class (used to represent hardware drivers)
Anyway, that's already more information than you asked for, but I find the naming issue to be relevant to the layout issue, since the real question is: what is the best way to organize my code for a large xCode project?
无论如何，这已经比您要求的信息多，但我发现命名问题与布局问题有关，因为真正的问题是：为大型 xCode 项目组织代码的最佳方法是什么？
Hope it helps. Here is how it all looks when put together:
希望能帮助到你。这是放在一起时的样子：
[+] 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
回答by Kendall Helmstetter Gelner
The second option makes way more sense as your project grows.
随着项目的发展，第二种选择更有意义。
Furthermore, the default project has xib files go into "resources" but again as a project grows it makes a lot more sense to move related files into a logical group for some screen or other piece of functionality.
此外，默认项目将 xib 文件放入“资源”，但随着项目的增长，将相关文件移动到某个屏幕或其他功能的逻辑组中会更有意义。
One grouping arrangement by way of example would be:
举例来说，一种分组安排是：
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)
The App delegate could hang out in Utilitites, or perhaps just floating above all those groups under Classes.
App 委托可以挂在 Utilitites 中，或者可能只是漂浮在 Classes 下的所有那些组之上。
回答by Li Fumin
Option 2 makes more sense to me.Think about it ,while you are coding,you always editing around the "view" and its controller,option 2 makes you find the appropriate files in the most efficient way.
选项 2 对我来说更有意义。想想看，当你编码时，你总是围绕“视图”及其控制器进行编辑，选项 2 让你以最有效的方式找到合适的文件。
回答by Tony Eichelberger
Sometimes the best practice is to do what most makes sense to you. I personally like the grouping by functionality, but either way it can become unwieldy if you are not thoughtful about meaningful names and refactoring names when they no longer describe the functionality.
有时最好的做法是做对你最有意义的事情。我个人喜欢按功能分组，但无论哪种方式，如果您不考虑有意义的名称和重构名称，当它们不再描述功能时，它就会变得笨拙。
回答by mmc
I don't know that there is a standard organization in XCode, especially since project organization inside the IDE often does not translate to file organization on disk.
我不知道 XCode 中有一个标准组织，特别是因为 IDE 内部的项目组织通常不会转换为磁盘上的文件组织。
That said, I usually do something similar to your Option 1, for no better reason than that more closely resembles the folder structure in Rails, which is what I was most used to when I started messing with the iPhone.
也就是说，我通常会做一些类似于你的选项 1 的事情，没有更好的理由比它更类似于 Rails 中的文件夹结构，这是我开始使用 iPhone 时最习惯的。
回答by A.G
The standard Xcode MVC folder structure is as follows.
标准的 Xcode MVC 文件夹结构如下。
CoreData : Contains DataModel and Entity Classes.
Extension : Contain One class(default apple class extensions+project class extensions.)
Helper: Contain Third Party classes/Frameworks (eg. SWRevealController) + Bridging classes (eg. Obj C class in Swift based project)
Model : Make a singleton class (eg.AppModel - NSArray,NSDictionary, String etc.) for saving data. The Web Service Response parsing and storing data is also done here.
Services : Contain Web Service processes (eg. Login Verification, HTTP Request/Response)
View : Contain storyboard, LaunchScreen.XIB and View Classes. Make a sub folder Cells - contain UitableviewCell, UICollectionView Cell etc.
Controller: Contain Logic or Code related to UIElements (eg. UIButton's reference+ clicked action)
CoreData ：包含数据模型和实体类。
扩展：包含一个类（默认苹果类扩展+项目类扩展。）
Helper：包含第三方类/框架（例如 SWRevealController）+ 桥接类（例如基于 Swift 的项目中的 Obj C 类）
模型：制作一个单例类（例如 AppModel - NSArray、NSDictionary、String 等）来保存数据。Web Service Response 解析和存储数据也在这里完成。
服务：包含 Web 服务进程（例如登录验证、HTTP 请求/响应）
View ：包含 storyboard、LaunchScreen.XIB 和 View 类。创建一个子文件夹 Cells - 包含 UitableviewCell、UICollectionView Cell 等。
控制器：包含与 UIElements 相关的逻辑或代码（例如 UIButton 的引用+点击动作）
Refer :
参考 ：
https://github.com/futurice/ios-good-practices#common-librarieshttp://akosma.com/2009/07/28/code-organization-in-xcode-projects/
https://github.com/futurice/ios-good-practices#common-libraries http://akosma.com/2009/07/28/code-organization-in-xcode-projects/
Note: I have mentioned AppModel and AppController classes (They are singleton classes like AppDelegate)
注意：我已经提到了 AppModel 和 AppController 类（它们是像 AppDelegate 这样的单例类）
回答by Sakthimuthiah
Please refer the following link. Hope it helps !
请参考以下链接。希望能帮助到你 ！
http://akosma.com/2009/07/28/code-organization-in-xcode-projects/(Please note "Conclusion Structure" in this link - At the end of this link)
http://akosma.com/2009/07/28/code-organization-in-xcode-projects/（请注意此链接中的“结论结构” - 在此链接的末尾）
