Closed idva closed 8 years ago
lazarev
commented
8 years ago Здравствуйте, Ирина!
А возможно ли еще упомянуть ваше видение подходов к преобразованию JSON данных в объекты модели данных приложения и обратно? Эти процессы обычно сильно связаны с валидацией. Очень интересно узнать о стратегиях обновления существующих объектов, об удобных вариантах сосуществования нескольких схем маппинга, если такое есть.
idva
commented
8 years ago Андрей, добрый день!
Пожелание поняла, но, боюсь, про маппинг в докладе я рассказывать не буду. Я считаю, что валидация данных и маппинги не должны быть связаны. Например, если провести аналогию с тестами, то при изменении кода они должны ломаться, и это правильно. Тесты не должны быть написаны универсально, чтобы они автоматически оставались рабочими после изменения кода. При валидации логика похожая, если меняется иерархия данных и маппинги, то должна сломаться валидация. Вносить изменения нужно в двух местах, но это обезопасит от многих потенциальных проблем. Другая причина - это сингл респонсибилити, валидатор - валидирует, маппер - маппит. Детали того и другого остаются втайне, мы спокойно можем переехать на другую библиотеку маппинга, не затронув при этом валидацию.
Про поводу подходов к преобразованию JSON данных в объекты модели мы подумаем, возможно, из этого выйдет отдельный доклад. Спасибо!
Валидация JSON-ответа сервера
Клиент-серверное взаимодействие лежит в основе большинства мобильных приложений. Язык общения между клиентом и сервером всегда закреплён определённым контрактом. Однако валидация этого контракта незаслуженно остаётся в стороне. Отсюда и большинство проблем на клиенте - некорректное отображение, неконсистентность данных и падения. Этих проблем можно избежать, добавив предварительную валидацию.
В докладе будут рассмотрены: