Форум программистов, компьютерный форум CyberForum.ru

Программирование iOS/iPhone

Войти
Регистрация
Восстановить пароль
 
kievkao
42 / 42 / 2
Регистрация: 22.11.2012
Сообщений: 225
#1

Разные стеки CoreData - Программирование iOS/iPhone

12.11.2015, 15:15. Просмотров 369. Ответов 0
Метки нет (Все метки)

Всем привет!

Наткнулся я недавно на статью Маркуса Зарры, где он описывает то, как он организовывает свой стек CoreData. Заинтересовало, начал искать другие статьи, и в конечном итоге вывел для себя 5 разных стеков, которые рекомендует народ.
Не по всем стопроцентно понял, почему они организованы именно так, поэтому хотел бы привести их все, свои соображения (которые, возможно, тоже кому-то пригодятся) по ним, и был бы очень рад услышать комментарии, где я ошибся..

1) Первый стек, дефолтный, который генерит сам XCode:
Main Context
|
Coordinator
|
Store

Подходит для простых проектов, где у нас пару сущностей в CoreData, и в процессе записи/чтения оттуда мы не оперируем сотнями-тысячами объектов.

2) Стек, собственно, от Маркуса Зарры:
Main Context
|
Private Context
|
Coordinator
|
Store

Подходит для таких себе Middle проектов, где запись/чтение из CoreData отнимает достаточное время, которое мешает плавной работе UI.
Непосредственно с хранилищем связан Private контекст, который педалит всю тяжеловесную работу, связанную с I/O в фоновом потоке и никому не мешает. Если мы создаем объекты, то все равно делаем это в Main Context (т.е. главном потоке), но, учитывая то, что мы за один раз никогда тонны объектов не создаем, то нас это не волнует. Так как в итоге самые длительные операции (чтение-запись) у нас выполняет Private context.

3) Стек с рабочими приватными контекстами:
Private Context, Private Context, ..., Private Context
|
Main Context
|
Private Context
|
Coordinator
|
Store

Структура похитрее. В проекте может быть создание за раз большого кол-ва объектов, запись/чтение такого же большого объема, но и одновременно с этим у нас есть где-то FetchedResultsController, через который надо в главном потоке "прогонять в онлайн-режиме" все свежезаписанные и свежепрочитанные объекты.
Получается, мы загрузили с какого-то нашего бекэнда тонну инфы, в фоновом потоке одного из верхних Private контекстов создали все нужные NSManagedObject's (что занимает длительное время) и скомандовали save().
Объекты поплыли вниз по иерархии, прошли Main Context, который подвязан к нашему FetchedResultsController, он сразу отобразил наши изменения.
Ну и после прохождения Main контекста, объекты попадают в нижний Private, где непосредственно стартует тяжеловесная запись в хранилище.

4)
Main Context, Private Context, ..., Private Context
|
Coordinator
|
Store

Вверху у нас есть один Main, и сколько угодно Private.
Если у нас есть FetchedResultsController для определенного типа данных, которые к нам приходят на запись понемного, и их надо сразу показывать при получении - мы суем их в MainContext. А также есть все остальные данные, которые приходят тоннами, но их нам юзеру прям щас показывать не надо, поэтому мы их спокойно скармливаем Private Context'у и он их спокойно в фоне пишет в хранилище.
Мы же можем подписаться на какой-нибудь NSManagedObjectContextDidSaveNotification, получать уведомление, когда эти тонны запишутся через фоновый контекст, и подбирать их не спеша в наш Main для отображения.

5)
Main Context
|
Private Context, Private Context, ..., Private Context
|
Coordinator
|
Store

Есть верхний Main контекст, у которого parent - Private, который уже, в свою очередь, присоединен к хранилищу. А также есть N отдельных Private контекстов, которые тоже имеют связь с хранилищем.
По аналогии с предыдущим вариантом у нас есть N Private контекстов, через которые мы пишем тяжеловесные данные, не требующие моментального отображения. И связка Main-Private, через которую мы работаем с данными, которые, одновременно, надо записывать в хранилище в фоне, но и вместе с тем надо прогонять через главный поток для использования в FetchedResultsController.

Добавлено через 2 минуты
Спасибо всем, кто прочитал))

Еще раз повторюсь - если кто-то заметил ошибку в моем понимании этих структур, расскажите, пожалуйста, в чем ошибка..

В частности, у меня есть сомнение по поводу того, зачем нужен промежуточный контекст в Main потоке, кроме как для того, чтобы использовать его в связке с NSFetchedResultsController'ом, который, как я понимаю, умеет работать только с Main контекстами.
Есть ли еще кейсы, когда прям никак без Main контекста не обойтись?
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
12.11.2015, 15:15     Разные стеки CoreData
Посмотрите здесь:

Сравнения sqlite3 и coredata
CoreData , наследование
Objective-C Array в CoreData
CoreData and FetchRequest
Покритикуйте мой метод работы с CoreData
Разные цвета у Search Bar и Button
Plist или coredata
Редактирование CoreData
Разные устройства/ориентации
Насколько рационально хранение изображений в CoreData
CoreData: как сохранить только одну entity из множества созданных
Swift CoreData "Список пользователей"

Искать еще темы с ответами

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

Текущее время: 07:41. Часовой пояс GMT +3.
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru