Советы по преобразованию приложения iPhone 2.x в 3.0 с Core Data - PullRequest
2 голосов
/ 02 августа 2009

У меня есть приложение, разработанное для iPhone OS 2.x. По очевидным причинам классы моделей в этом приложении были написаны без Core Data.

Теперь, когда 3.x доступен, я хотел бы знать, каковы некоторые из моих вариантов взять мои существующие классы моделей и перестроить их с помощью Core Data. Я делаю много вещей с моими моделями, помимо очевидных, таких как сериализация и сохранение их в базе данных sqlite3, чтобы мое приложение могло работать, когда нет сетевого подключения. Я ожидаю, что Core Data сможет помочь мне и в этом.

Кроме того, с учетом включения Core Data в ваше приложение, есть ли какая-либо причина по-прежнему использовать sqlite3? Будете ли вы по-прежнему использовать его для таких вещей, как предоставление автономного контента, хранение статистики, которая не обязательно имеет смысл для создания модели? Или есть способы включить все это в базовые данные?

Ответы [ 2 ]

2 голосов
/ 03 августа 2009

Основные преимущества использования Core Data в приложениях для iPhone:

  • Сохранение ссылочной целостности
  • Миграция управляемой модели при изменениях схемы
  • предоставление объектного реляционного отображения
  • Значительно упрощенный процесс вставки, соединения и запроса - например, объединения, как правило, выполняются с помощью "точечного" синтаксиса
  • Наложение нескольких хранилищ (хотя поищите мой вопрос об стеке потока, чтобы узнать, работает ли он на sqllite, все еще ожидая ответа ...)
  • Построение структурированных предикатов - вы можете создавать свои предикаты как объекты вместо встроенных встроенных SQL-операторов
  • Рефлексивное хранилище данных - вы можете анализировать хранилище данных во время выполнения структурированным и статически анализируемым способом

Тем не менее, если ваше приложение уже разработано для работы с базой данных sqllite, вам действительно нужно спросить себя, готовы ли вы преобразовать ваше приложение.

Вам нужно будет сделать хотя бы следующие вещи:

  • Перестройка всей схемы базы данных в моделях управляемых объектов Core Data
  • Переписать все ваши запросы к базе данных и управление для использования Core Data
  • Переписать все ваши модели, чтобы они были либо поддержаны сгенерированными Базовыми данными управляемыми объектами, либо расширяли их
  • Импорт всех существующих данных вручную в базу данных Core Data
  • Будьте готовы к написанию гораздо большего количества кода! Хотя Core Data обеспечивает хорошую объектную среду для работы с запросами и управлением хранилищем данных, это также происходит за счет многословия.
  • Для продолжения предыдущего пункта, когда вы сделаете даже относительно небольшие изменения в своей схеме, вы будете готовы потратить относительно значительное количество времени на предоставление схемы и ее правильное применение к существующим схемам.

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

Чтобы ответить на ваш второй вопрос, я не могу придумать причину для непосредственного использования sqllite, если вы используете Core Data, если честно. Я не уверен, что внешние объединения, к примеру, ужасно просты в Core Data. Однако вы обычно не используете Core Data таким образом - вы бы использовали его процедурно для создания того же эффекта, что и внешнее соединение в SQL.

Для статистики и прочего я бы по-прежнему использовал Core Data, поскольку он предоставляет некоторые фантастические функции агрегирования.

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

0 голосов
/ 03 августа 2009

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

Для чего-то вроде вашей установки, подход, который я, вероятно, выбрал бы для миграции, это чтобы каждый класс модели держался за управляемые объекты, которые на самом деле являются классами хранения - тогда весь ваш код не должен был бы изменяться, только некоторые вещи в объекты модели и, возможно, классы управления, которые вы могли бы построить для создания или заполнения объектов модели. Это даже скрывает проблему с примитивом NSNumber.

Если вы серьезно рассматриваете возможность работы с Базовыми данными, возможно, вы захотите взглянуть на эту книгу, которая также охватывает специфичные для iPhone Базовые данные (включая NSFetchedResultsController):

http://www.pragprog.com/titles/mzcd/core-data

Вы можете купить электронную книгу только в разблокированном формате PDF, что не так уж и дорого ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...