Какие шаги нужно предпринять для преобразования моего XML в объекты Core Data? - PullRequest
Новая
       60

Какие шаги нужно предпринять для преобразования моего XML в объекты Core Data?

2 голосов
/ 19 февраля 2010

У меня есть XML-файл, который содержит списки магазинов, упрощенная версия приведена ниже. В чем я хотел бы помочь, так это в общих чертах о самых простых способах перемещения этих данных в объекты для хранения в Core Data. Я вижу предложения относительно пар ключ-значение, но, как вы можете видеть в моем примере ниже, у меня есть дочерние элементы с тем же именем / ключом, и их может быть произвольное число для каждого элемента магазина.

Я намерен хранить эти объекты в приложении для будущего использования (они будут аннотациями на карте). Итак, каждое дублированное поле необходимо сохранить, одного из них будет недостаточно. Я знаю, как смоделировать это в Базовых данных, я полагаю, у меня будет сущность телефонного номера и сущность магазина, и я просто сопоставлю их на основе <store-id>. Я просто пытаюсь использовать простой метод для перемещения их из XML в базовые данные через какую-то другую структуру данных.

Пример XML: 

<stores>
  <store>
   <store-id>1</store-id>
   <city>Dublin</city>
   <phone>011234567</phone>
   <phone>011234566</phone>
   <owner>Joe Bloggs</owner>
  </store>
  <store>
   <store-id>2</store-id>
   <city>Cork</city>
   <phone>019876543</phone>
   <phone>019876542</phone>
   <owner>Joe Bloggs</owner>
  </store>
<stores>

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

Спасибо

Ответы [ 3 ]

5 голосов
/ 19 февраля 2010

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

После того, как вы разработали модель данных, вы можете использовать NSXMLParser или стороннюю библиотеку, такую ​​как TouchXML, для анализа XML. Начните с вашего элемента. Для каждого элемента создайте объект на основе объекта хранилища. Для каждого телефона в элементе создайте телефонную сущность и т. Д.

0 голосов
/ 02 августа 2011

Просто на базовом уровне, не очень .. Я не могу понять , где вы указываете это, возможно, когда вы впервые создаете модель ... но один из вариантов для хранилища данных это как .plist, который является XML для всех интенсивных целей ...

например ... этот список "старой школы", извлеченный непосредственно из модели базовых данных .. 

(
Editorial,
News,
Retraction,
"FLAME!",
)

- это те же данные, что и этот набор XML, один раз пройденный через

/usr/bin/plutil -convert xml1 /../input.plist -o /../output.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
    <string>Editorial</string>
    <string>News</string>
    <string>Retraction</string>
    <string>FLAME!</string>
</array>
</plist>
0 голосов
/ 19 февраля 2010

Рискну предположить, что подход «создай при разборе», вероятно, будет не только самым простым, но и наименее ресурсоемким подходом. Если вы можете использовать потоково-ориентированный синтаксический анализатор для обработки XML и сохранять хранилища после завершения их анализа, это гораздо меньше вещей, которые вы должны хранить в памяти за раз.

Я бы также серьезно подумал о том, должны ли атрибуты быть полноценными объектами или просто свойствами магазина. Например, вы будете делать что-нибудь с именем владельца, кроме того, чтобы отображать его на карте? (И да, я видел ваш комментарий о том, что эта конкретная вещь просто пример.)

К сожалению, Core Data на самом деле не предоставляет хороший способ создать многозначное свойство, которое не является отношением. (Телефонные номера здесь действительно выглядят так, как будто они могут быть просто массивом строк.) Хотя см. этот вопрос SO и эту тему какао-разработчика для некоторого обсуждения этого.

...