Смущен тем, как использовать JSON в C #

Question

Ответ почти на каждый вопрос об использовании C # с JSON , кажется, "использовать JSON.NET", но это не тот ответ, который я ищу.

Причина, по которой я говорю, заключается в том, что из всего, что я смог прочитать в документации, JSON.NET - это просто более эффективная версия DataContractSerializer, встроенная в .NET Framework ...

Это означает, что если я хочу десериализовать строку JSON, я должен определить полный строго типизированный класс для КАЖДОГО запроса, который у меня может быть. Поэтому, если мне нужно получить категории, сообщения, авторов, теги и т. Д., Я должен определить новый класс для каждой из этих вещей.

Это нормально, если я построил клиент и точно знаю, что это за поля, но я использую чужой API, поэтому я не представляю, что это за контракт, если я не скачаю образец строки ответа и не создам класс вручную из строка JSON.

Это единственный способ сделать это? Разве нет способа заставить его создать своего рода хеш-таблицу, которую можно прочитать с помощью json ["propertyname"]?

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

Так каков же общий рабочий процесс при работе с JSON? И вообще, я имею в виду библиотечно-независимость. Я хочу знать, как это делается в целом, а не специально для целевой библиотеки ...

Answer 1

Очень сложно быть независимым от библиотеки, когда вы запрашиваете, потому что то, как вы работаете с json, действительно зависит от используемой вами библиотеки. Например, в JSON.NET есть несколько способов работы с JSON. Есть метод, о котором вы говорите с прямой сериализацией в объекты. Это безопасный тип, но он сломается, если данные из вашего API изменятся. Однако есть также LINQ-to-JSON, который предоставляет JObject (который ведет себя почти так же, как XElement), который предоставляет способ сделать JObject ["key"], как вы и просили в своем вопросе. Если вы действительно ищете гибкий способ работы с JSON внутри C #, то посмотрите LINQ-to-JSON JSON.NET.

На самом деле, независимо от того, как вы это сделаете, если API изменит ваш код, скорее всего, сломается. Даже если вы просто используете подход, основанный на хеш-таблицах, ваш код все равно может сломаться, если возвращающиеся данные изменятся.

Редактировать

Документация JSON.NET

Примеры

Если вы ознакомитесь с примерами, второй должен дать вам хороший пример того, как работает LINQ-to-JSON. Это позволяет вам работать с ним без определения каких-либо классов. Все преобразуется в стандартные классы фреймворка (в основном, коллекции и строки). Это избавляет от необходимости поддерживать классы.

Answer 2

Я был разработчиком Perl более десяти лет, и я только недавно начал работать на C #. Я удивлен тем, насколько мне это нравится (я вообще не люблю Java), но один из самых сложных когнитивных переключателей идет от «Все можно рассматривать как строку, а язык заботится о преобразованиях» к «Предварительно -определите ваши типы. " В этом случае строковое мышление может быть преимуществом, потому что это то, что вам нужно сделать для того типа API, который вы запрашиваете.

Вам нужно написать анализатор JSON, который понимает синтаксис , который довольно прост: разделенные запятыми списки, пары ключ / значение, {} для хэшей / объектов, [] для массивов и цитирование / избегать конструкций. Вы захотите создать Hashtable для запуска, потому что сущность верхнего уровня в JSON всегда является объектом, а затем сканируйте строку JSON посимвольно. Вытащите пары ключ / значение; если значение начинается с {, то добавьте его как новый Hashtable, если оно начинается с [добавьте его как новый ArrayList, в противном случае добавьте его как строку. Если вы получили {или [вам нужно будет рекурсивно спускаться, чтобы добавить дочерние элементы данных.

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