Каков стандартный способ организации кода iPhone MVC в XCode? - PullRequest
16 голосов
/ 05 июня 2009

У меня есть приложение для 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

Вариант 1, кажется, имеет больше смысла с точки зрения MVC - код сгруппирован, но мне интересно, когда приложение расширяется до 10+ представлений и контроллеров, является ли это наиболее логичным и поддерживаемым? Есть ли лучшие рекомендации по этому поводу? В настоящее время я буду единственным, кто будет поддерживать приложение, но независимо от того, будет ли несколько разработчиков, я хочу использовать как можно больше рекомендаций. Существуют ли опубликованные стандарты по этому вопросу?

Ответы [ 7 ]

18 голосов
/ 05 июня 2009

Я сейчас работаю над большим проектом 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
4 голосов
/ 05 июня 2009

Второй вариант приобретает все больший смысл по мере роста вашего проекта.

Кроме того, в проекте по умолчанию 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.

1 голос
/ 21 сентября 2015

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

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

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

  3. Помощник: содержит сторонние классы / фреймворки (например, SWRevealController) + Мостовые классы (например, класс Obj C в проекте на основе Swift)

  4. Модель: создайте одноэлементный класс (например, AppModel - NSArray, NSDictionary, String и т. Д.) Для сохранения данных. Здесь также выполняется синтаксический анализ и хранение отклика Web-сервиса.

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

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

  7. Контроллер: содержит логику или код, относящиеся к элементам UIE (например, ссылка UIButton + нажатие кнопки)

См .:

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

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

1 голос
/ 05 июня 2009

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

1 голос
/ 05 июня 2009

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

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

1 голос
/ 05 июня 2009

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

0 голосов
/ 01 апреля 2014

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...