Что стандартный путь состоит в том, чтобы организовать код iPhone MVC в XCode?
Если вы хотите использовать NetBeans для определения таблиц, прочитайте это https://codezone4.wordpress.com/2012/06/19/java-database-application-using-javadb-part-1/ Просто определите столбец как целое число и создайте базу данных, затем захватите структуру во временный файл, затем удалите таблицу. Щелкните правой кнопкой мыши папку с таблицами и выберите пересоздать таблицу, выберите сохраненный файл и отредактируйте сценарий для автоматического увеличения.
5 ответов
Я сейчас работаю над большим проектом xCode. Это не для iPhone, но я не думаю, что это важно для разметки файловой структуры :)
Я начал с варианта №1, а позже перешел к чему-то вроде варианта №2, когда количество файлов увеличилось. . Я обычно группирую вещи по «интерфейсам», т. Е. Все источники, связанные с определенной областью функциональности в приложении, а затем при необходимости создаю подгруппы для более крупных разделов.
Что касается именования, я предпочитаю чтобы идентифицировать Модель, Представление и Контроллер, используя как можно меньшее количество имен классов, так что имена моих классов выглядят примерно так:
AM_DillPickle // model class
AV_Sasquatch // view class
AC_DirtBike // controller class
Это все еще позволяет быстро визуально проверить тип класса (M, V или C), но оставляет больше места для описательной части имени.
I ' Мы также сочли полезным указать некоторые классы, которые не вписываются в шаблон 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
Второй вариант становится более понятным по мере роста вашего проекта.
Кроме того, в проекте по умолчанию файлы 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 или, возможно, просто парить над всеми этими группами под классами.
Иногда лучше всего делать то, что вам больше всего подходит. Мне лично нравится группировка по функциональности, но в любом случае она может стать громоздкой, если вы не задумываетесь о значимых именах и рефакторинге имен, когда они больше не описывают функциональность.
Вариант 2 имеет для меня больше смысла. Подумайте об этом, пока вы пишете код, вы всегда редактируете "представление" и его контроллер, вариант 2 позволяет вам найти подходящие файлы в большинстве эффективный способ.
Я не знаю, есть ли в XCode стандартная организация, тем более что организация проекта внутри IDE часто не переводится в файловую организацию на диске.
Тем не менее, я обычно делаю это. что-то похожее на ваш Вариант 1, но только потому, что это больше похоже на структуру папок в Rails, к чему я больше всего привык, когда начал возиться с iPhone.