Альтернативы Core Data на iOS

Я разрабатывал несколько приложений для iOS с использованием Core Data, и это была отличная среда для работы. Однако я столкнулся с проблемой, из-за которой мы более или менее распределяли объекты (синхронизировали) между несколькими платформами. Серверная часть веб-сервера/базы данных и мобильные устройства.

Хотя до сих пор это не было проблемой, статическая природа модели данных, используемой Core Data, меня немного запутала. В основном запрашивается система динамических форм, в которой формы могут создаваться на сервере и распространяться на устройства. Я знаю технику выполнения этого с заданным количеством таблиц с чем-то вроде:

  • Таблица форм
  • Таблица полей
  • Экземпляр таблицы Forms
  • Таблица значений экземпляров

и просто связывая все вместе. Однако мне интересно, существует ли альтернативная система Core Data (что-то выше, напрямую связанное с базой данных SQLite), которая позволит использовать более динамичный граф объектов. Даже стандартная ORM была бы хороша, если бы были варианты изменения схемы во время выполнения. Основная причина, по которой я хочу пойти по этому пути, - это производительность в том смысле, что я не хочу, чтобы таблица значений экземпляра взрывалась записями (на локальном устройстве или сервере).

Мой другой вариант - иметь статическую схему (граф объекта) на устройствах iOS, но иметь слой преобразования на стороне сервера, который извлекает правильный объект, заполняет свойства и сохраняет его в правильной таблице. Затем, когда устройства синхронизируются, он делает обратное и разбивает их на экземпляры. Хотя это избавляет сервер от раздутой таблицы значений экземпляров, это все же может быть проблемой на устройстве.

Любые предложения приветствуются.


ios objective-c core-data orm object-graph
person Dave Finster    schedule 21.07.2011    source источник
comment
эй @Dave как насчет этого? github.com/LakithaRav/OLCOrm   -  person Laky    schedule 03.08.2016

Ответы (2)


arrow_upward
1
arrow_downward

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

Однако, если схема будет меняться нечасто, вы, вероятно, можете сделать это с помощью Core Data. Вы можете программно создавать и/или манипулировать NSManagedObjectModel перед созданием NSManagedObjectContext. Вы также можете создать логику миграции, чтобы данные, хранящиеся в старой модели, могли быть сохранены при обновлении модели и необходимости воссоздания контекста и хранилищ.

Эти другие сообщения SO могут быть полезны:

person Daniel Dickison    schedule 21.07.2011
comment
Ах, я искал некоторые подробности об изменении MOM во время выполнения. Спасибо за эти ссылки. На самом деле я не ожидаю, что модель будет часто меняться, однако я просто учитываю масштабируемость приложения (особенно на мобильном устройстве). Из документации я предполагаю, что как только модель будет изменена (что благодаря фоновой обработке может произойти во время стандартного выполнения), мне придется перезагрузить постоянное хранилище (и выполнить миграцию и т. д.) и повторно инициализировать все, что связано с базой данных. Это выполнимо, и, используя эту технику, я смогу разделить модель данных между платформами. - person Dave Finster; 22.07.2011

arrow_upward
0
arrow_downward

Вам нужно тщательно подумать о том, что вы на самом деле моделируете.

Вы моделируете: (1) фактические «формы», то есть элементы пользовательского интерфейса, (2) данные, которые могут быть представлены в любом количестве версий пользовательского интерфейса, например. firstName или (3) оба?

Модель данных, предназначенная для моделирования форм, будет иметь такие объекты, как:

Form{
  name:string
  fields<-->Field.form
}

Field{
  width:number
  height:number
  xPos:number
  yPos:number
  label:sting
  nextTab<-->Field.priorTab
  priorTab<-->Field.nextTab
  form<<-->Form.fields
}

Вы могли бы использовать это для хранения данных о форме, отображаемой в пользовательском интерфейсе. Тогда у вас будут отдельные объекты и, возможно, отдельная модель для хранения фактических данных, которые будут заполнять элементы пользовательского интерфейса, настроенные первой моделью данных.

Вы можете использовать Core Data для моделирования чего угодно, просто нужно знать, что вы на самом деле моделируете.

person TechZen    schedule 22.07.2011
comment
Я собираюсь хранить как информацию для пользовательского интерфейса, так и фактический макет данных объектов формы. Главное здесь то, что сами формы динамические (клиент, бэкэнд многотенентный) и как таковой граф объектов меняется. Я могу либо моделировать на основе фиксированных таблиц, описывающих объекты, либо динамически строить объектную модель во время выполнения на основе сервера. Причина, по которой я хочу использовать отдельные таблицы для каждого шаблона, заключается в том, что мы можем получить много данных. Я знаю, что вы не хотели думать о Core Data как о базе данных, но с точки зрения производительности это необходимо учитывать. - person Dave Finster; 23.07.2011
comment
Похоже, вам может понадобиться дизайн на основе документов вместо стандартного стека Core Data. В дизайне документа каждый документ имеет свой собственный стек, и документ на самом деле представляет собой просто постоянное хранилище, содержащее только информацию, связанную с одним логическим документом. В вашем случае каждый документ может состоять из двух хранилищ: хранилища для форм пользовательского интерфейса и хранилища данных, отображаемых в формах. Если каждый раз все по-разному, то нет дизайна или API, нужно втиснуть все эти различия в один большой магазин. - person TechZen; 23.07.2011
comment
Я знаю, что это для iOS, но посмотрите на класс MacOS NSPersistentDocument, чтобы понять, как Core Data работает с архитектурой документа. - person TechZen; 23.07.2011