Каков стандартный способ организации кода iPhone MVC в XCode?

Ответ 1

Сейчас я работаю над большим проектом xCode. Это не для iPhone, но я не думаю, что это важно для компоновки файловой структуры:)

Я начал с опции № 1 и позже перешел к чему-то вроде опции №2, когда число файлов увеличилось. Я склонен группировать вещи с помощью "интерфейсов", то есть всех источников, связанных с определенной областью функциональности в приложении, а затем, при необходимости, создавать подгруппы для больших разделов.

Что касается именования, я предпочитаю идентифицировать Model, View и Controller, используя как можно меньше объектов класса, поэтому имена классов похожи на:

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

Ответ 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)

Делегат приложения может выходить в Utilitites или, возможно, просто плавать над всеми этими группами под классами.

Ответ 3

Иногда лучшая практика заключается в том, чтобы делать то, что для вас наиболее важно. Мне лично нравится группировка по функциональности, но в любом случае это может стать громоздким, если вы не задумываетесь о значащих именах и именах рефакторинга, когда они больше не описывают функциональность.

Ответ 4

Я не знаю, что в XCode есть стандартная организация, тем более что организация проекта внутри IDE часто не переводит на файловую организацию на диск.

Тем не менее, я обычно делаю что-то похожее на ваш вариант 1, по лучшей причине, чем те, которые более похожи на структуру папок в Rails, к чему я больше всего привык, когда начал общаться с iPhone.

Ответ 5

Вариант 2 имеет больше смысла для меня. Подумайте об этом, пока вы кодируете, вы всегда редактируете вокруг "view" и его контроллера, вариант 2 позволяет вам находить соответствующие файлы наиболее эффективным способом.

Ответ 6

Пожалуйста, обратитесь к следующей ссылке. Надеюсь, это поможет!

http://akosma.com/2009/07/28/code-organization-in-xcode-projects/ (Обратите внимание на "Структура заключения" в этой ссылке - В конце этой ссылки)

Ответ 7

Стандартная структура каталогов Xcode MVC выглядит следующим образом.

• CoreData: содержит классы DataModel и Entity.

• Расширение: Содержит один класс (расширения класса Java по умолчанию + расширения класса проекта.)

• Помощник: Содержит классы сторонних разработчиков /Framework (например, SWRevealController) + Классы мостов (например, класс Obj C в проекте на основе Swift)

• Модель: создайте класс singleton (например, AppModel - NSArray, NSDictionary, String и т.д.) для сохранения данных. Здесь также выполняются синтаксический анализ и сохранение данных веб-службы.

• Службы: содержат процессы веб-службы (например, проверка входа, HTTP-запрос/ответ)

• Вид: Содержит раскадровку, LaunchScreen.XIB и классы просмотра. Сделайте подпапку Ячейки - содержат UitableviewCell, UICollectionView Cell и т.д.

• Контроллер: содержит логику или код, связанные с UIElements (например, ссылка UIButtons + действие с щелчком)

Обратитесь:

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

Примечание. Я упомянул классы AppModel и AppController (они являются одноэлементными классами, такими как AppDelegate)