Restkit с (сложными) отношениями и Core Data / RAILS - PullRequest
Новая
       35

Restkit с (сложными) отношениями и Core Data / RAILS

3 голосов
/ 13 сентября 2011

Пожалуйста, потерпите меня, потому что я только учусь какао. Я прошел некоторые уроки, касающиеся Core Data, сейчас я изучаю RESTkit, чтобы использовать его с приложением Rails. Я также прочитал все документы, рецепты решений на вики-странице RESTkit (особенно iOS SDK: Advanced RestKit Development была очень полезна).

Ради простоты я собираюсь использовать очень ограниченное количество моделей / отношений в этом вопросе.

Предположим, у меня есть следующие модели: компания, человек, язык со следующими отношениями: 

company many-to-many person
language 1-to-many person

и синхронизация RAILS и приложения для iOS.

В определенное время в приложение Rails вводится новый человек, связанный с существующей компанией и существующим языком: например. Стив Джобс> Дисней, Стив Джобс> Английский В то же время новый человек добавляется в новую компанию, и новый язык например. Анна Куриникова> Nike, Анна Курникова> Русская

Теперь, как мне настроить решение для синхронизации? Я мог бы попросить JSON-дамп всех новых людей: 

[{"person": {
    "id": 123,
    "name": "Steve Jobs",
    "language": {
        "id": 1,
        "name": "English"
    },
    "company": {
        "id": 1,
        "name": "Disney"
    }
  }},
  {"person": {
    "id": 124,
    "name": "Anna Kournikova",
    "language": {
        "id": 22,
        "name": "Russian"
    },
    "company": {
        "id": 47,
        "name": "Nike"
    }
  }}]

Теперь мои вопросы:

1) может (и если да, то как?) RESTkit создать и связать новую компанию и язык. Я полагаю, что для существующей компании это не проблема, но новых в моих базовых данных еще нет.

2) существует ли способ избежать необходимости включать все данные о компании и языке, так как в реальном приложении это создаст огромные накладные расходы на данные, которые уже существуют на устройстве iOS, если люди будут добавлены в существующие компании

3) может быть подход, при котором сначала выбираются все новые языки, все новые компании, а затем выбираются все новые люди, и только идентификатор языка / компании, к которой они относятся, является лучшим подходом в этом смысле ( для сохранения полосы пропускания) но я не делаю много вещей вручную, которые RESTkit может делать автоматически?

4) что если существующий человек связан со второй компанией?

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

1 Ответ

4 голосов
/ 13 сентября 2011

Позвольте мне попытаться ответить на ваши вопросы по одному:

  1. Да, при правильной настройке сопоставления RestKit может создавать новые компании и языки из вышеуказанного JSON.

  2. Да, вы можете избежать выборки вложенных данных о компании и языке в пользу внешних ключей company_id и language_id, которые можно использовать во время сопоставления для подключения нового лица к существующим компаниям и / или языкам в вашем локальном магазине. Проверьте следующее API сопоставления:

    • (void) connectRelationship: (NSString *) RelationsName withObjectForPrimaryKeyAttribute: (NSString *) primaryKeyAttribute;

Для № 3 и № 4 вам нужно будет укрепить свой дизайн API сервера, прежде чем на них можно будет конкретно ответить. Вы предлагали использовать вложенный JSON в этом вопросе, но также задавали вопросы о том, что вы не можете использовать вложенный JSON и даже разбить вышеупомянутый JSON на несколько запросов. Сценарий, который вы описали в # 4, может быть обработан RestKit, но специфика того, как на самом деле зависит от того, какие вызовы вы делаете на сервер и какая полезная нагрузка возвращается в ответ на эти вызовы. Я рад предоставить здесь дополнительную помощь, но, в конце концов, я уверен, что RestKit сможет справиться с вашими случаями использования, поскольку специфика конфигурации сопоставления во многом зависит от того, как вы завершили работу с серверным API.

...