При принятии решения о том, какое постоянство использовать, важно помнить, что Core Data - это, прежде всего, система управления графом объектов. Его истинная функция - создать уровень модели времени выполнения для шаблонных приложений проектирования Модель-Представление-Контроллер. Постоянство на самом деле является вторичной и даже необязательной функцией Core Data.
Основными проблемами моделирования / устойчивости являются размер данных и сложность данных. Итак, относительные сильные и слабые стороны каждого типа настойчивости будут разбиты следующим образом:
_______________________________
| | |
2 | | |
| SQL | Core Data | 4
s | | |
i |_______________ ______________|
z | | |
e | | |
1 | Collection | Core Data | 3
| plist/xml | |
| | |
-------------------------------
Complexity--->
К которому мы могли бы добавить третий параметр арендодателя, волатильность, то есть как часто меняются данные.
(1) Если размер, сложность и изменчивость данных низкие, то использование коллекции, например Лучшим вариантом будет NSArray, NSDictionary, NSSet сериализованного настраиваемого объекта. Коллекции должны полностью считываться в память, чтобы ограничить их эффективный размер сохраняемости. У них нет управления сложностью, и все изменения требуют перезаписи всего файла сохраняемости.
(2) Если размер очень большой, но сложность невысока, тогда SQL или другой API базы данных могут обеспечить превосходную производительность. Например. старомодная система каталожных карточек библиотеки. Каждая карта идентична, карты не связаны между собой и карты не имеют поведения. SQL или другие процедурные БД очень хороши для обработки больших объемов информации низкой сложности. Если данные простые, то SQL может эффективно обрабатывать даже очень изменчивые данные. Если пользовательский интерфейс столь же прост, то интеграция пользовательского интерфейса в объектно-ориентированный дизайн приложения iOS / MacOS сопряжена с небольшими накладными расходами.
(3) По мере того, как данные становятся более сложными, Core Data быстро становится лучше. «Управляемая» часть «управляемых объектов» управляет сложностью отношений и поведения. С коллекциями или SQL вы вручную управляете сложностью и можете быстро оказаться в затруднительном положении. Фактически, я видел людей, пытающихся управлять сложными данными с помощью SQL, которые в конечном итоге пишут свой собственный миниатюрный стек Core Data. Излишне говорить, что когда вы объединяете сложность с изменчивостью, Core Data становится еще лучше, потому что автоматически обрабатывает побочные эффекты вставки и удаления.
(Сложность интерфейса также вызывает беспокойство. SQL может обрабатывать большие статические отдельные таблицы, но когда вы добавляете иерархии таблиц, которые могут изменяться на лету, SQL становится кошмаром. Core Data, NSFetchedResultsController и UITableViewController / делегаты делают это тривиально.)
(4) Благодаря высокой сложности и большому размеру Core Data, безусловно, является лучшим выбором. Core Data сильно оптимизирован, поэтому увеличение размера графа не приводит к тому, что происходит в такой степени, как в случае с SQL. Вы также получаете очень интеллектуальное кэширование.
Кроме того, не путайте «Я хорошо понимаю SQL, но не Core Data» с «Core Data имеет высокие накладные расходы». На самом деле это не так. Даже когда Core Data - не самый дешевый способ передачи и вывода данных из хранилища, их интеграция с остальной частью API обычно дает превосходные результаты, если учитывать скорость разработки и надежность.
В данном конкретном случае из описания я не могу сказать, в каком случае вы находитесь: в случае (2) или в случае (4). Это зависит от внутренней сложности данных И сложности пользовательского интерфейса. Ты говоришь:
Я не думаю, что хочу создать модель Core Data с сотнями сущностей, а затем использовать картограф для импорта в нее JSON.
Вы имеете в виду реальные абстрактные объекты или просто управляемые объекты? Помните, что сущности относятся к управляемым объектам, а классы относятся к экземплярам. Если первое, то да, Core Data потребует много работы заранее, если второе, то этого не будет. Вы можете построить очень большие сложные графы всего с двумя или тремя связанными сущностями.
Помните также, что вы можете использовать конфигурацию для помещения разных сущностей в разные хранилища, даже если все они используют один контекст во время выполнения. Это может позволить вам поместить временную информацию в одно хранилище, использовать ее как более постоянные данные, а затем удалить хранилище, когда вы закончите с ним.
Core Data дает вам больше возможностей, чем может показаться на первый взгляд.
person
TechZen
schedule
09.03.2011
