Дизайн модели CoreData: является ли чрезмерное использование NSFetchRequest симптомом плохо спроектированной модели?

Question

Базовые объекты данных можно получить с помощью NSFetchRequest или следуя отношениям с другими объектами на графике.Справедливо ли говорить, что в хорошо спроектированной модели будут содержаться достаточные отношения (и извлеченные свойства), чтобы использование NSFetchRequests было сведено к минимуму?

Аргументом противодействия является то, что в iOS существует NSFetchedRequestController.Предположительно, если бы Apple считала, что отношения и извлеченные свойства обеспечивали удовлетворительную производительность при существующем сбое / кэшировании, они бы не создали NSFetchedRequestController.

Существуют случаи, когда использование NSFetchRequest лучше, поскольку Core Data может делать всеработа в SQLite.Примером будет выборка агрегированных значений.

Есть мысли по этому поводу?Я взглянул на Руководство по программированию основных данных .В разделах «Извлечение управляемых объектов» и «Производительность базовых данных» есть соответствующие рекомендации, но нет ничего, что могло бы настоятельно рекомендовать отношения по запросам на выборку или наоборот.

Answer 1

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

--------------  1           * ------------
| Department |<------------->>| Employee |
--------------                ------------
| name       |                | name     |
--------------                | age      |
                              | salary   |
                              ------------

Если вы хотите получить всех сотрудников, принадлежащих к определенному отделу, тогда уместно придерживаться отношения «Department.employees».Неуместно создавать NSFetchRequest для сущности Employee с предикатом 'отдела == xxxx'.

И наоборот, если вы хотите найти сотрудников для определенного отдела с зарплатой> x, тогда целесообразно использоватьNSFetchRequest с предикатом типа «отдел == ххххх И зарплата> х».Нецелесообразно извлекать всех сотрудников, использующих отношение Department.employees, а затем выполнять итерацию по ним в цикле, чтобы найти высокодоходных.

Таким образом, отношения или NSFetchRequests по своей природе не являются "хорошими" или "плохой'.Просто используйте их соответствующим образом.Используйте отношения для навигации вашего графа объектов.Используйте NSFetchRequest для выполнения поиска по подмножеству или там, где вам нужна гибкость возврата результатов в виде словарей или нужно использовать NSExpressions.

РЕДАКТИРОВАТЬ В ДОБАВИТЬ:

Множество NSFetchRequests было засорено по всему вашему коду является признаком плохого дизайна.Я всегда инкапсулирую запросы данных в пользовательских классах NSManagedObject и стараюсь не вызывать какие-либо вызовы Core Data в коде контроллера представления / просмотра.

Извлеченные свойства, я полагаю, способ достижения того же самого.Я предпочитаю создавать NSFetchRequest в коде, а не использовать редактор Core Data для этого.Он гораздо более гибкий, но в действительности оба способа представляют собой одно и то же.

Answer 2

Когда вы разрабатываете модель в coredata, вы должны иметь в виду, что если у вас есть 1, 2 или n отношений в режиме, это означает, что ваш граф объектов будет вести себя так же, как и база данных SQL, потому что он будет выбирать только основные строки. , кроме вашего приложения явно нужно в первом запросе все объекты. Фактически Apple поощряет разделение вашей модели по отношениям из соображений производительности, поэтому, когда ошибка вашей модели при извлечении в этот момент извлечет остальное. Единственный аспект, который вам следует позаботиться о правилах удаления (null, cascade ...), поскольку неправильно разработанное правило удаления может привести к сбою или повлиять на производительность. Поверьте мне, я никогда не видел ничего более эффективного, чем основные данные. Сделайте сильную модель, а основные данные сделают все остальное.

Одно из моих приложений (Mariette) использует основные данные, а другое (billingfiles) использует SQL

Answer 3

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

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