Хранилища данных для нескольких платформ.Должен ли я использовать CoreData для нашей среды?

Question

У нас есть собственные приложения, которые работают на Android, iOS и Windows Mobile.Для других устройств (таких как BlackBerry) мобильное веб-решение.Эти приложения в настоящее время делают первоначальный большой выбор из нашей CMS, а затем анализируют XML из нашей CMS в качестве хранилища данных.Эти данные затем доступны в автономном режиме на устройстве.Мы ищем что-то более элегантное, чем XML, когда масштабируем.

Вот варианты, которые мы взвешиваем:

Вариант 1. Экспорт sqlite DB в Android, iOS и телефон Windows 7что все они затем использовали бы в качестве хранилища данных.

Плюсы: CMS экспортирует один и тот же формат данных на все устройства

Минусы: iOS не использует CoreData, как все, что я читал, говорит, что яследует использовать.

Вариант 2. Экспортировать sqlite DB на все платформы, но iOS вставляет данные в CoreData.Мы играем с идеей о том, чтобы CMS экспортировал формат JSON в iOS и вставил iOS в CoreData, так как наши дельта-обновления приложения будут в JSON.

Плюсы: iOS использует CoreData и все ее преимущества.

Минусы: iOS теперь отличается от всех других наших платформ, так что ей требуется промежуточное решение (преобразование данных в хранилище CoreData.)

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

3/22/2013 для небольших уточнений и грамматических изменений.

Answer 1

Наткнулся на это решение во время исследования: https://github.com/AlexDenisov/iActiveRecord

Он ведет себя подобно CoreData, так что он использует графы объектов.Он создает операторы SQL за кулисами, поэтому вам не нужно заботиться о написании запросов.

Что мне нравится в этом решении, так это то, что iActiveRecord указывает на нашу экспортированную базу данных SQLite из нашей CMS (которая использует django), и мы просто определяем наш класс Obj-C, чтобы соответствовать схемам таблицы (аналогично определению данныхмодели в CoreData.) После того, как схемы классов определены, чтобы отразить наши схемы таблиц, мы можем начать использовать объекты, не беспокоясь о SQL-запросах.

CoreData не смогла сделать это, поскольку нам потребовалось написать «преобразователь» вполучить экспортированные данные из нашей CMS в хранилище данных CoreData.

Конечно, все дополнительные навороты CoreData отсутствуют, но для наших случаев использования iActiveRecord взвешивал другие варианты.

Answer 2

Реальный вопрос: действительно ли вы можете использовать какой-либо код на этих платформах? Немного. Наверное, слишком мало, чтобы беспокоиться об этом. На самом деле, если у вас нет общей библиотеки C / C ++ (в широком смысле, как в наборе функций ) для обработки данных в базе данных SQLite, мало кода для повторного использования.

Могут быть случаи, когда вы сильно зависите от определенных SQL-запросов для хорошей производительности. Эти запросы могут оказаться очень неэффективными в Core Data. В этом сценарии я бы пошел с SQLite и FMDB .

Если запросы достаточно просты и вам, в основном, необходимо отображать / редактировать данные, то использовать Core Data будет проще.