Управление нумерованного Core Data Отношения Использование NSArrayController

Question

Все эти «NSOrderedSet был добавлен позже, и, таким образом, не должен играть хорошо с другими компонентами» ошибки сводишь меня с ума ...

(https://twitter.com/kubanekl/status/413447039855640576)

У меня есть два управляемых объекта и упорядоченное соотношение 1: N между ними, которое поддерживается экземпляром (или более точным подклассом) NSOrderedSet. Я хочу управлять этими отношениями с помощью NSArrayController, чтобы получить прибыль от функций, которые он предлагает (управление выбором, привязка контента, привязки к просмотрам, например NSTableView).

Поскольку NSOrderedSet не подкласс NSSet, то contentSet связывания NSArrayController не работает с этой взаимосвязью. Я нашел following thread и попытался реализовать упомянутые там предложения.

Первое предложение заключается в использовании связывания contentArray и трансформатора значения для преобразования упорядоченного набора в массив на лету. Проблема с этим решением заключается в том, что переназначает контента каждый раз, когда производится изменение, чего я не хочу.

Второе предложение, приведенное в упомянутой теме, заключается в использовании связывания contentArray и применении оператора @array к пути ключа модели. Я пробовал это, но базовое отношение было не касалось вообще при добавлении/удалении объектов через NSArrayController.

Другой вариант, который я нашел, это использовать дескрипторы сортировки с привязкой contentSet. Это потребовало бы, чтобы отношение было неупорядоченным, чтобы сделать работу по связыванию contentSet и ввести новый атрибут , используемый, в частности, для управления порядком. Кроме того, для этого потребуется пользовательский механизм заказа, и он будет испортить модель. Честно говоря, я хотел бы избежать этого решения.

Мой вопрос довольно ясен: есть ли способ управлять упорядоченными отношениями данных ядра с использованием NSArrayController? Если да, это лучший способ, вызывающий как можно больший боль?

Answer 1

Очень грустно, что NSArrayController не поддерживает упорядоченные отношения. Будучи острого наблюдателя в технологии привязок, я считаю его оптимальным, что кажется, что Apple «отказалась» от него, ничего не сказав. Последним заметным изменением, которое Apple внесла в отношении привязок, являются исправления ошибок NSTreeController. Я полагаю, что 10.6/10.7. Похоже, что Apple больше не хочет касаться технологии привязок. Я не уверен, почему, потому что привязки действительно велики иногда. Они могут быть «90% -ным решением». Во время прототипирования это нормально. Я использую привязки, где это имеет смысл, и NSArrayController с поддержкой упорядоченных отношений будет чем-то большим.

Большинство решений, о которых уже упоминалось, не являются реальными решениями. Но это зависит. Вот о чем подумать:

1. Если вы планируете поддерживать iCloud, вы не должны/не можете использовать упорядоченные отношения, так как Core Data на iCloud не поддерживает их.
2. Поскольку упорядоченные отношения довольно новы, и желание упорядоченного набора объектов существовало задолго до них, в Core Data должен быть способ имитировать упорядоченные отношения. Вы уже указали на то, что 99,9% от мира, использующего основные данные, было до того, как были доступны упорядоченные отношения: Сортировка по дополнительному атрибуту. Вы указали, что это испортит модель, но я не согласен: правда, вам нужно добавить дополнительный атрибут вашей модели, который не обязательно «представляет» истинные данные модели. Но сколько заказов вы планируете иметь в своей модели? Обычно у вас не так много на одно приложение. Несмотря на то, что он чувствует себя немного грязным, это то, что было сделано многими людьми по крайней мере для трех основных выпусков Core Data (10.4, 10.5 и 10.6). Даже сегодня это решение используется для обратной совместимости или если вы хотите использовать iCloud. Это «прагматичное» решение. Нехорошо, но прагматично. Также не нужно: даже если вы использовали упорядоченные отношения, порядок ваших объектов должен быть где-то сохранен. Если вы используете хранилище SQLite, то наличие упорядоченного отношения заставляет NSSQLiteStore создавать дополнительный столбец для вас. Столбец имеет имя: Z_FOK_ $ RELATIONSHIPNAME. Поэтому, используя упорядоченные отношения, вы просто делаете то, что делается для вас под капотом. Это означает, что с технической точки зрения это не имеет значения, если вы используете упорядоченные отношения или дополнительный атрибут. Основные технические проблемы остаются неизменными. Упорядоченные отношения не волшебство.
3. Если вы планируете использовать «дополнительный атрибут», имейте в виду, что вам нужно многократно изменять значение этого атрибута: каждый раз, когда пользователь меняет заказ с помощью перетаскивания, вам нужно изменить значение атрибут. Это кажется расточительным, но на самом деле это не так. Даже худший случай: пользователь, который обменивает объект в строке 0 с объектом в последней возможной строке, вызывает только 2 изменения атрибута. Сложность тривиального решения для изменений, необходимых для представления любых изменений, которые могут быть сделаны путем перетаскивания в виде таблицы, - это O (n), где n - количество выбранных строк. Это действительно не так уж плохо, поскольку пользователи обычно не переупорядочивают 10000000 строк одновременно, и даже тогда есть более разумные алгоритмы, которые не так сложно реализовать.
4. Если вы ищете самое чистое решение, вы должны подклассифицировать NSArrayController и добавить привязки «orderedContentSet» самостоятельно. Вы можете узнать, как это сделать, прочитав руководство по программированию Bodings Cocoa. В руководстве содержится пример: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html (листинг 2). Плохая вещь в том, что вы подклассифицируете NSArrayController, который обычно не идет. Многие люди склонны подклассифицировать NSArrayController по причинам, которые не оправдывают его подклассификацию. В этом случае, однако, подкласс NSArrayController оправдан, если вы хотите пойти с самым чистым решением.
5. Для 3. Есть общие решения, которые делают много вещей для вас. Не используйте их.