Основные испытания данных

Question

Несколько недель назад я решил изучить Core Data для своего нового проекта и применить его ко всей моей модели. Была крутая кривая обучения, но в итоге я познакомился со стэком, и теперь мне довольно удобно, по крайней мере, с базовыми концепциями и несколькими распространенными ловушками, такими как параллельность потоков.

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

В качестве конкретного примера мое приложение извлекает несколько фрагментов данных с моего сервера (сообщений), которые появляются в фиде. Каждый пост имеет владельца, класса User, который я также получаю с сервера. Теперь Core Data отлично справляется с управлением реальностью между почтой и пользователем. Связь обновляется автоматически, и получение источника сообщения так же просто, как и вызов post.owner. Тем не менее, есть также неудобства:

1. Основные данные заставляют объекты на диск, которые я не хочу принуждать к диску. Это, вероятно, главная проблема. С сообщениями я не хочу, чтобы они были вынуждены диск, и предпочли бы снова звонить на сервер. Зачем? Поскольку больше должностей, которые я храню настойчиво, тем больше домашнее хозяйство нужно делать. Сообщение может быть отредактировано, удалено, помечено и т. Д. ... и локальное сохранение этих сообщений означает необходимость планировать обновления.

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

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

Итак, каковы ваши рекомендации относительно основных данных? Вы бы предложили другой подход к Core Data?

Я думал о гибридном кэшировании + данных ядра, где я храню информацию, которую я на самом деле использую многократно (например, пользователей), а затем использую ОЗУ для таких вещей, как сообщения, или просто создаю сообщения без NSManagedContext. Добро пожаловать!

Answer 1

Основные данные заставляют объекты на диск, которые я не хочу принуждать к диску.

Это не так. Если вы не хотите сохранять свои объекты Post в постоянном хранилище, не помещайте их в базовые данные и не создавайте им управляемые объекты. Ваш объект User может иметь свойство posts, даже если объект Post не управляется Core Data. Управляемые объекты могут иметь свойства любого типа, а не только для других управляемых объектов.

Необходимо постоянно беспокоиться о параллельности контекстов, объектов и т.п.

Параллельность сложна независимо от того, как вы моделируете свои данные. Это принципиально сложная проблема. Вы сталкиваетесь с этим с Core Data, потому что используете Core Data. Если вы используете что-то еще, вы будете иметь дело с ним.

Снижение производительности.

Меню «Продукт» -> «Анализировать» и запускать инструменты, чтобы узнать, почему. Нет причин, по которым это должно произойти, и у вас есть инструменты, чтобы узнать, что происходит на самом деле.