Советы по преобразованию приложения iPhone 2.x в приложение 3.0 с Core Data

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

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

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


person Coocoo4Cocoa    schedule 02.08.2009    source источник
comment
stackoverflow.com/questions/523482/core-data-vs-sqlite3   -  person titaniumdecoy    schedule 02.08.2009


Ответы (2)


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

  • Сохранение ссылочной целостности
  • Управляемая миграция модели при изменении схемы
  • обеспечение объектно-реляционного отображения
  • Значительно упрощенный процесс вставки, соединения и запроса - например, соединения обычно просто выполняются с использованием синтаксиса, разделенного точками.
  • Наложение нескольких хранилищ (хотя поищите мой вопрос о stackoverflow по этому поводу, чтобы узнать, действительно ли он работает на sqllite, все еще ожидая ответа ...)
  • Структурированное построение предикатов - вы можете создавать свои предикаты как объекты вместо встроенных встроенных операторов sql.
  • Отражающее хранилище данных - вы можете анализировать хранилище данных во время выполнения в структурированном и статически анализируемом виде

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

Вам нужно будет сделать как минимум следующее:

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

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

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

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

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

person groundhog    schedule 02.08.2009

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

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

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

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

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

person Kendall Helmstetter Gelner    schedule 02.08.2009