При принятии решения о том, какое постоянство использовать, важно помнить, что Core Data - это прежде всего система управления графами объектов.Это настоящая функция - создать слой модели времени выполнения шаблонных приложений Model-View-Controller.Постоянство на самом деле является вторичной и даже необязательной функцией базовых данных.
Основными проблемами моделирования / постоянства являются размер данных и сложность данных.Таким образом, относительные сильные и слабые стороны каждого типа постоянства будут разбиты следующим образом:
_______________________________
| | |
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) По мере усложнения данных базовые данные быстро становятся лучше.«Управляемая» часть «управляемых объектов» управляет сложностью отношений и поведения.С коллекциями или SQL вы можете вручную управлять сложностью и можете быстро справиться с задачей.На самом деле, я видел людей, пытающихся управлять сложными данными с помощью SQL, которые в конечном итоге пишут свой собственный миниатюрный стек Core Data.Нет необходимости говорить, что когда вы комбинируете сложность с волатильностью, Core Data становится еще лучше, потому что она автоматически обрабатывает побочные эффекты от вставки и удаления.
(Сложность интерфейса также вызывает беспокойство. SQL может обрабатывать большие статические единичные таблицы, но когда вы добавляете иерархии таблиц, которые могут меняться на лету, SQL становится кошмаром. Основные данные, NSFetchedResultsControllerи UITableViewController / делегаты делают его тривиальным.)
(4) Базовые данные с высокой сложностью и большим размером, безусловно, являются лучшим выбором.Базовые данные высоко оптимизированы, поэтому увеличение размера графа не так сильно мешает, как в SQL.Вы также получаете высокоинтеллектуальное кеширование.
Кроме того, не путайте: «Я хорошо понимаю SQL, но не базовые данные» с «базовыми данными, требующими больших затрат».Это действительно не так.Даже когда базовые данные не самый дешевый способ получить данные и сохранить их, их интеграция с остальной частью API обычно дает превосходные результаты, если учитывать скорость разработки и надежность.
В этом конкретном случаеслучай, я не могу сказать из описания, находитесь ли вы в случае (2) или случае (4).Это зависит от внутренней сложности данных и сложности пользовательского интерфейса.Вы говорите:
Я не думаю, что хочу создать модель Core Data с сотнями объектов, а затем использовать маппер для импорта в нее JSON.
Вы имеете в виду реальные абстрактные объекты здесь или просто управляемые объекты?Помните, что сущности относятся к управляемым объектам, а классы - к экземплярам.Если первое, то да Core Data будет много работы заранее, если второе, то не будет.Вы можете создавать очень большие сложные графы, используя только две или три связанных сущности.
Помните также, что вы можете использовать конфигурацию для помещения разных сущностей в разные хранилища, даже если все они совместно используют один контекст во время выполнения. Это может позволить вам поместить временную информацию в одно хранилище, использовать ее как более постоянные данные, а затем удалить хранилище, когда вы закончите с ним.
Базовые данные дают вам больше возможностей, чем может показаться на первый взгляд.