При десериализации JSON из программы c#, должен ли я когда-либо использовать что-либо, кроме JavaScriptSerializer?
.NET предоставляет класс JavaScriptSerializer в Система.Сеть.Скрипт.Пространство имен сериализации. (предоставляется в системе.Сеть.Увеличение.dll файлы)
первоначально он предназначался для поддержки приложений AJAX web server, но класс может использоваться любым приложением (клиент, сервер, гибрид, что угодно), которое сериализует и десериализует классы .NET в JSON. У меня есть настольное приложение, которое захватывает скриншоты и загружает в Facebook и использует этот класс для десериализации ответа.
хотел бы я когда-нибудь искать в другом месте десериализацию JSON из .NET?
Если да, то почему? и где мне искать?
Если нет, то почему JSON.Net существовать? Исключительно в исторических целях? (т. е., потому что он был создан сообществом до JavaScriptSerializer).
3 ответов
в моем случае есть разные причины, которые мешают мне использовать JavaScriptSerializer. Вот некоторые из них.
1) уродливая десериализация при работе с анонимными типами
Хотя использование довольно прямолинейно для сериализации:
JavaScriptSerializer serializer = new JavaScriptSerializer();
String json = serializer.Serialize(data);
для десериализации, однако, есть небольшое раздражение в том, что десериализатор принимает общий тип вместе с содержание:
serializer.Deserialize<T>(String s)
это может быть проблемой, если тип T не известен во время компиляции и должен быть динамичным. Работа вокруг немного уродлива, как я узнал, потому что она использует отражение для создания общего метода (но она работает)
var result = typeof(JavaScriptSerializer).GetMethod("Deserialize")
.MakeGenericMethod(JsonDataType)
.Invoke(serializer, new object[] { inputContent });
обратите внимание: согласно комментарию Дейва Уорда к этому ответу есть DeserializeObject()
Это можно использовать для предотвращения этого.
2) не может обработать круговыми ссылки
Я видел это с помощью Entity Framework, Linq to SQL, NHibernate, NetTiers и даже при использовании замок по доверенности.
по данным MS Connect исключение круговой ссылки будет возникать, когда судоходное отношение двустороннее (может получить доступ к обеим сторонам отношения), поэтому первое, что нужно сделать, это отключить одну сторону отношения. Исключение также будет вызвано при использовании отношений 1:1 (или 1:0..1 или любое отношение, вызывающее создание свойства типа EntityReference), в этом случае исключение будет иметь тип System.Data.Metadata.Edm.AssociationType
.
решение этого состоит в том, чтобы заставить сериализатор игнорировать свойства типа EntityReference, используя пустую реализацию класса, производного от JavaScriptConverter и регистрируя его с помощью метода RegisterConverters объекта JavaScriptSerializer.
3) полезные характеристики которые водят к более менее testable код
полезной особенностью JavaScriptSerializer является то, что вы также можете реализовать пользовательский JavaScriptConverter и передать его в JavaScriptSerializer для мелкозернистого управления сериализацией/десериализацией. Однако, чтобы это было действительно полезно, вам нужно знать типы во время компиляции и иметь ссылки на эти типы. Это действительно ограничивает полезность этой функции, потому что, ссылаясь на эти классы, ваш код становится тесно связанным, поэтому вы не можете легко используйте его в чем-то вроде фильтра MVC.
по этим причинам я часто заканчивал использовать Json.NET - ...
надеюсь, что это помогает!
Я использую JavaScriptSerializer на самых разных сценариях, он никогда не подводил меня, и никогда не нужно было искать в другом месте для других решений... :)
...но я знаю, что JSON.net имеет некоторые добавленные значения, такие как LINQ to JSON, которые мне никогда не нужны, и хорошее форматирование JSON, но по мере сериализации JavaScriptSerializer отлично работает.
Я бы не использовал сериализатор, поставляемый .Сеть. Посмотрите на этот пост, чтобы понять, почему:
и причина JSON.Net существует JavaScriptSerializer не появлялся до .Net 3.5. JSON.Net существовал до этого.