NSCoder по сравнению с NSDictionary, когда Вы используете что?

Я нашел решение.

$grouped = $collection->mapToGroups(function ($item, $key) {
    return [$item['filter'] => $item['value']];
});

$grouped->toArray();

https://laracasts.com/discuss/channels/eloquent/need-help-with-formatting-laravel-collection#reply=486863

9
задан Chris Hanson 17 January 2009 в 23:18
поделиться

4 ответа

Документация Apple относительно графов объектов говорит следующее:

Сериализация Mac OS X хранит простую иерархию объектов значения, таких как словари, массивы, строки и двоичные данные. Сериализация только сохраняет значения объектов и их положения в иерархии. Несколько ссылок на тот же объект значения могли бы привести к нескольким объектам при десериализации. Переменчивость объектов не сохраняется.

Архивы Mac OS X хранят произвольно диаграмму составного объекта. Архив сохраняет идентификационные данные каждого объекта в графике и всех отношениях, которые он имеет со всеми другими объектами в графике. При разархивировании восстановленный граф объектов должен, за редким исключением, быть точной копией графика исходного объекта.

Путем я интерпретирую, это - то, что, если Вы хотите сохранить простые значения, сериализация (использующий NSDictionary, например) является прекрасным способом пойти. Если Вы хотите сохранить граф объектов произвольных типов с уникальностью и переменчивостью, сохраненные, использующие архивы (с NSCoder, например) Ваш лучший выбор.

Можно также хотеть прочитать Руководство по программированию Архивов и Сериализации Apple для Какао, которого aforelinked страница на графах объектов является частью, поскольку это затрагивает эту тему хорошо.

9
ответ дан 4 December 2019 в 12:22
поделиться

Я не большой поклонник использования NSCoding/NSCoder/NSArchiver (мы должны выбрать имя!) для сериализации графа объектов в файл.

Архивы создали, таким образом невероятно хрупки. При сохранении объекта класса Foo затем ей-богу, необходимо удостовериться, когда Вы загружаетесь, данные назад в Вас имеют класс Foo в Вашем приложении.

Это делает базирующуюся сериализацию NSCoder трудной с точки зрения совместно использования файлов с другими приложениями или даже прямой совместимости с Вашим будущим приложением.

5
ответ дан 4 December 2019 в 12:22
поделиться

Я забыл перечислять то, что я рекомендую.

NSCoding может быть в порядке в определенных ситуациях: если Вы просто делаете что-то быстрое и простое (хотя действительно необходимо написать много кода - два метода в классе, который будет сериализирован). Может также быть хорошо, если Вы не волнуетесь по поводу совместимости с другими приложениями.

Экспорт/импорт с помощью списков свойств (возможно, использующий класс NSPropertyListSerializaion) является прекрасным решением. XML базирующийся plists легко создать и отредактировать. Основное преимущество для plists состоит в том, что Вы не связываете формат файла только с своим приложением.

Можно также создать собственный формат XML-файла и чтение-запись к нему с помощью NSXMLDocument API и друзья. Это действительно не намного больше работы, чем использование списков свойств.

2
ответ дан 4 December 2019 в 12:22
поделиться

Я думаю, что Вы немного смущены, NSDictionary является структурой данных, это также, оказывается, реализует протокол NSCoding. Так в сущности Вы могли или поместить все свои данные в NSDictionary и иметь, которые кодируют себя позже, или можно реализовать протокол NSCoding и закодировать дерево объектов с помощью API NSCoder. На основе типа объекта NSCoder, переданного в к encodeWithCoder: метод, вывод Вашего кодирования.

1
ответ дан 4 December 2019 в 12:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: