Основные альтернативы данных на iOS - PullRequest
Новая
       48

Основные альтернативы данных на iOS

4 голосов
/ 21 июля 2011

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

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

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

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

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

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

Ответы [ 2 ]

1 голос
/ 21 июля 2011

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

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

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

0 голосов
/ 22 июля 2011

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

Моделируете ли вы: (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 для моделирования всего, что вам нужно, чтобы знать, что вы на самом деле моделируете.

...