Objective-C, JSON и сопоставление объектов - PullRequest
Новая
       17

Objective-C, JSON и сопоставление объектов

2 голосов
/ 03 апреля 2012

Я делаю какой-то самодельный анализ и «сопоставление объектов», вы увидите, на данный момент не совсем сопоставление объектов, но это моя цель, мне нужно сначала найти лучший подход.

Пример текущего упрощенного кода

Parser

Сегодня у меня есть парсер, специально созданный для моего приложения, вот ключевой метод, вы получите его. 

-(void)jsonParserDidFinishParsing:(NSDictionary *)dic fromFile:(BOOL)file
{
    if ([dic objectForKey:@"timeline"]) {
        NSArray *items = [dic objectForKey:@"timeline"]; 
            for (NSDictionary *item in items) {
                MSTimelineItem *aItem = [[MSTimelineItem alloc]initWithDic:item]; 
                [delegate timelineParserDidParseAnItem:aItem];
            }
            [delegate timelineParserDidFinishParsing]; 
     }
}

Модель

У меня есть модели с каким-то стандартным конструктором, как этот (конечно, в моем реальном приложении ключи являются константами). 

-(id)initWithDic:(NSDictionary *)dic
{
    self = [super init]; 
    if (self) {
        _udid = [dic objectForKey:@"udid"]; 
        _picUrl = [dic objectForKey:@"profile"]; 
        _name = [dic objectForKey:@"name"]; 
        _job = [dic objectForKey:@"job"]; 
    }
    return self; 
}

Цель

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

подход

Избегайте всего этого конструкторского кода, мой подход заключается в использовании KVC, именовать свойства с тем же именем, что и ключи JSON, и сохранять только мои свойства @ dymanic для вычисляемых вещей. Так что я могу буквально зацикливаться в свойствах dic JIC и использовать setObject:ForKey из парсера.

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

проблемы

У меня есть некоторый объект с отношением, например модель может содержать массив других моделей. Все еще нужна логика, чтобы справиться с этим. Также сохраняя все свойства можно еще много кода.

Также доступ к или установка свойств, которые не существуют, приведет к сбою приложения. Что я могу сделать против этого?

Заключение

Во всех случаях мне все еще нужно знать ключи / свойства в какой-то момент. Доступ к свойствам объектов лучше, чем object:forKey, так как я получу мгновенное предупреждение и ошибки.

Я не хочу использовать фреймворк, такой как RESTKit, я создал свой собственный фреймворк для вещей Rest, мне нужен только этот динамический подход, чтобы иметь полностью стандартный набор классов.

Я также знаю, что у меня нет знаний, чтобы придумать более продуманное решение, твой ход:)

Вопрос

Я прав? Каков наилучший подход с точки зрения вашего опыта, мне действительно интересно услышать, что вы делали раньше, почему это сработало, почему это хорошо или нет.

Надеюсь, вам понравилась презентация;)

1 Ответ

2 голосов
/ 03 апреля 2012

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

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

Если ваш API возвращает изменяющуюся структуру JSON (опять же, не рекомендуется), тогда я бы предложил полностью отказаться от архитектуры отображения моделей и просто использовать NSDictionary для хранения ответа.

Я предполагаю, что камнем преткновения здесь является то, что если вы хотите, чтобы объектная модель отображалась в вашем API, то вы подразумеваете, что существуют заданные модели для передачи, и если это так, то просто создайте свойства, соответствующие JSON и не беспокойтесь о красоте / технически. Сохраняй это простым.

...