При десериализации 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 отлично работает.


Я бы не использовал сериализатор, поставляемый .Сеть. Посмотрите на этот пост, чтобы понять, почему:

http://www.reddit.com/r/linux/comments/epd5z/microsoft_standards_and_incompatibility_19912010/c19v88j

и причина JSON.Net существует JavaScriptSerializer не появлялся до .Net 3.5. JSON.Net существовал до этого.