Комментарии 12
Я тут недавно писал про JSON Schema validator. Если пройтись по озвученный минусам, то эта реализация поддерживает mapping; не нужно создавать класс для каждого ключа json'а; полная проверка входных данных, в том числе и типа класса в массивах; небольшой объем исходного кода.
Но меня на написание своего велосипеда толкнуло полное отсутствие уже готовых решений. Mapping получился в итоге сам собой + все плюшки валидатора
Но меня на написание своего велосипеда толкнуло полное отсутствие уже готовых решений. Mapping получился в итоге сам собой + все плюшки валидатора
Ну например, к нам приходит json, у которого по ключику «data» — массив обьектов, которые нужно замапить в наш обьект (назовем его MyClass). Тогда нужно лишь описать схему:
Mетод -jsonSchema сам создаст схему для нашего класса (все проперти)
После этого, каждый объект в массиве будет провалидирован в соответствии с этой схемой, и если нужно уже провалидированный json будет инстанциирован в обьекты нашего MyClass. Каждый ключик будет соотнесен со свойством инстанса и присвоен ему.
Не нужные нам объекты так и остаются NSDictionary и NSArray
[[SVType object] properties:@{
@"data":[ @[ [MyClass jsonSchema] ] jsonSchema],
}];
Mетод -jsonSchema сам создаст схему для нашего класса (все проперти)
После этого, каждый объект в массиве будет провалидирован в соответствии с этой схемой, и если нужно уже провалидированный json будет инстанциирован в обьекты нашего MyClass. Каждый ключик будет соотнесен со свойством инстанса и присвоен ему.
Не нужные нам объекты так и остаются NSDictionary и NSArray
если не нужно на каждый объект json создавать по obj-c объекту — оч круто, снимаю шляпу, повнимательнее посмотрю на ваш фреймворк и внутренности его
хотя мне начинает казаться, что я не до конца правильно понял, что значит «создаст схему для нашего класса (все проперти)» — он рантаймом создаст реальные проперти в классе или засетит просто?
Основная идея в том, что создается схема. По сути это описание json'а с указанием того, какие у каких объектов есть свойства, какие у них могут быть значения (если это массив, то какие объекты он может содержать, если число — то какой дианазон оно может принимать, являются ли какие-либо поля строго обязательными и т.д) Вот обзорная статья на хабре . Так вот, метод jsonSchema как раз и создает такую схему для уже существующих классов.
На каждый json объект создавать класс это имхо как-то сурово. Когда мне понадо бился маппер, я нашел github.com/mystcolor/JTObjectMapping и не сожалею)
судя по примеру на гитхабе, у этого маппера та же история, что и у моего — в итоге пришлось создать два класса со всеми нужными проперти — JTSocialNetworkTest и JTUserTest для довольно не сложного json, разве что используя его не пришлось писать свой велик)
в моем маппере для
тоже не пришлось ничего дополнительно создавать, так что минус с «объект json = объект obj-c» оба мапера решают одинаково
в моем маппере для
"p_childs" = (
Mary,
James
)
тоже не пришлось ничего дополнительно создавать, так что минус с «объект json = объект obj-c» оба мапера решают одинаково
В вашем маппере нравится в первую очередь простота. Но по ходу это единственный его плюс. А теперь о том, что не нравится:
1) Модель уже не модель
Теперь у неё есть методы для парсинга объектов и методы для настройки этих методов. И они будут с ней в памяти навсегда.
Здесь мне больше всё же нравится подход управления моделью снаружи.
2) Необходимость создавать модели даже для всех вложенных объектов.
Если данные какого-то json объекта разбиты на несколько групп для простоты их понимания, то я не хочу создавать одну общую модель и несколько вложенных. В этом случае я хочу иметь одну модель и для её свойств указать пути для получения значений. Ну или что-то в этом роде.
Самое меньшее, что здесь нужно реализовать – добавить возможность хранить вложенный объект в виде словаря без принудительного парсинга. Тогда хотябы костылями можно добиться нужного поведения в сложных случаях.
Упомянутый выше JTObjectMapping по моему мнению хуже вашего в виду необходимости явно указывать поля для маппинга. А я же в качестве более навороченной альтернативы могу упомянуть github.com/dchohfi/KeyValueObjectMapping. Кроме описанной мной выше необходимости создавать одну модель из нескольких объектов он сможет делать и противоположную вещь – создавать несколько вложенных моделей на основе плоских данных.
1) Модель уже не модель
Теперь у неё есть методы для парсинга объектов и методы для настройки этих методов. И они будут с ней в памяти навсегда.
Здесь мне больше всё же нравится подход управления моделью снаружи.
2) Необходимость создавать модели даже для всех вложенных объектов.
Если данные какого-то json объекта разбиты на несколько групп для простоты их понимания, то я не хочу создавать одну общую модель и несколько вложенных. В этом случае я хочу иметь одну модель и для её свойств указать пути для получения значений. Ну или что-то в этом роде.
Самое меньшее, что здесь нужно реализовать – добавить возможность хранить вложенный объект в виде словаря без принудительного парсинга. Тогда хотябы костылями можно добиться нужного поведения в сложных случаях.
Упомянутый выше JTObjectMapping по моему мнению хуже вашего в виду необходимости явно указывать поля для маппинга. А я же в качестве более навороченной альтернативы могу упомянуть github.com/dchohfi/KeyValueObjectMapping. Кроме описанной мной выше необходимости создавать одну модель из нескольких объектов он сможет делать и противоположную вещь – создавать несколько вложенных моделей на основе плоских данных.
абсолютно с вами согласен по всем пунктам, я сам использую свой маппер зачастую в небольших проектах, когда простота принципиальнее всего остального, при этом очень часто сервер пишу либо я сам либо человек, сидящий возле меня, и существует реальная возможность влиять на json) на досуге подумаю над вашими замечаниями
кстати, я внезапно осознал, маппер умеет «Самое меньшее, что здесь нужно реализовать – добавить возможность хранить вложенный объект в виде словаря без принудительного парсинга», просто не нужно указывать в keyToClassMappingRules ключи, которые хотим оставить без парсинга)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Супер простой iOS JSON mapper