Обновление счетчика основных данных

Question

У меня есть базовая модель данных с группами блогов, блогами и постами.Группа блогов имеет отношение ко многим с блогами, а каждый блог имеет отношение ко многим с сообщениями.Сообщение имеет атрибут "hasBeenRead."И блог, и группа блогов имеют атрибуты «numberUnreadPosts».

Я хотел бы знать, как лучше распространять число непрочитанных постов в каждой взаимосвязи.Например, если я читаю пост, я бы хотел уменьшить количество непрочитанных постов на единицу как в блоге, так и в группе блогов.Спасибо!

Answer 1

Есть несколько способов сделать это.

Наблюдатель KVO

Ваша группа BlogGroup может наблюдать за изменениями в свойстве объекта Blog -numberUnreadPosts и при его изменении может обновляться самостоятельно.

Аналогично, ваш блог может следить за изменениями свойства сущности Post -hasBeenRead и, когда он изменяется, он может обновляться, что будет распространяться вплоть до BlogGroup.

Проблема с этим дизайномчто предполагается, что сущности BlogGroup и Blog находятся в памяти (поскольку вы включили бы наблюдателя в методе -awakeFromFetch).Это может не всегда иметь место, и я считаю, что лучше не полагаться на эту ситуацию.

Распространение обновления

Когда сообщение изменяет свойство -hasBeenRead, вы можете переопределить установщик и получитьэто называют его родителем (Блог) и говорят это об изменении.Затем блог обновит свой непрочитанный счетчик и сообщит блоггруппе, что он обновился.

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

Или не беспокойтесь об этом

Третий вариант заключается в том, что значение имеет только сообщение.Затем вы можете создать удобный метод как для Blog, так и для BlogGroup, который просто подсчитывает непрочитанные из объектов ниже.

Это довольно просто сделать, но это не наблюдаемое свойство, поэтому может не работать в вашем дизайне..

Дизайн вашего приложения определит, какой дизайн вам больше подходит.Если вы знаете, что BlogGroup и Blog всегда будут реализованы, когда вы работаете с сообщением, тогда вариант 1 - лучшее решение imho.

Answer 2

Без использования извлеченных свойств (что я не сделал - возможно, это правильный путь), я бы пошел вверх от сообщений. Создайте запрос на выборку для сущности Post с предикатом для hasBeenRead == NO. Итерируя по полученному массиву, используйте обратную связь, чтобы определить Блог, владеющий каждым постом, и BlogGroup, владеющий каждым Блогом, и создать два словаря.

Первый словарь имеет уникальное имя Post-> Blog в качестве ключа, если для него нет записи, вы создаете и сохраняете [NSValue valueWithInt: 1] для ключа, иначе увеличиваете то, что там есть. Второй словарь такой же, но имеет идентификатор Post-> Blog-> BlogGroup в качестве ключа. Непрочитанный счетчик для Blog или BlogGroup можно найти, посмотрев на значение, сохраненное для соответствующего ключа.

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

Answer 3

Звучит как работа для Полученные свойства