Какая разница между DataContractJsonSerializer и JavaScriptSerializer?

.NET Framework поставляется с System.Runtime.Serialization.Json.DataContractJsonSerializer и System.Web.Script.Serialization.JavaScriptSerializer, оба из которых дезацифровывают JSON. Как узнать, когда выбрать один из этих типов над другим? MSDN не дает понять, каковы их относительные преимущества.

У нас есть несколько проектов, которые потребляют или выделяют JSON, и класс, выбранный для каждого из них до сих пор, зависел от мнения первичного разработчика по каждому проекту. Некоторые из них просты, два имеют сложную логику в отношении создания управляемых типов из JSON (типы не привязаны близко к потокам), но не имеют никакого акцента на скорости, требуется скорость. Никто не взаимодействует с WCF, по крайней мере, на данный момент.

В то время как меня интересуют альтернативные библиотеки, я надеюсь, что у кого-то может быть и ответ на мой вопрос.

Ответ 1

DataContractJsonSerializer предназначен для использования с клиентскими приложениями WCF, где сериализованные типы обычно представляют собой классы POCO с атрибутом DataContract, применяемым к ним. Нет DataContract, без сериализации. Механизм отображения WCF делает отправку и получение очень простой, но только если ваша платформа однородна. Если вы начнете смешивать в разных наборах инструментов, ваша программа может идти вбок.

JavaScriptSerializer может сериализовать любой тип, включая анонимные типы (в одну сторону), и делает это более согласованным образом. Вы теряете "автоматическое" WCF, но получаете больше возможностей интеграции.

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

2014-04-07 ОБНОВЛЕНИЕ: Я предлагаю использовать JSON.NET, если можно. См. http://james.newtonking.com/json Сравнение функций для обзора 3 библиотек, рассмотренных в этом вопросе.

2015-05-26 ОБНОВЛЕНИЕ: Если ваша компания требует использования коммерчески доступных продуктов или вам нужен последний бит производительности, вы также можете проверить https://servicestack.net/.

Ответ 2

Оба делают примерно то же самое, но используют очень разную инфраструктуру, тем самым применяя различные ограничения на классы, которые вы хотите сериализовать/десериализовать, и обеспечить разную степень гибкости в настройке процесса сериализации/десериализации.

Для DataContractJsonSerializer вы должны пометить все классы, которые вы хотите сериализовать, используя DataContract atrtibute и все члены, используя атрибут DataMember. Кроме того, если некоторые из вас имеют члены перечисления, то перечисления также должны быть отмечены как DataContract, а каждый член перечисления - с атрибутом EnumMember. Кроме того, DataContractJsonSerializer позволяет точно контролировать весь процесс сериализации/десериализации, изменяя логику разрешения типов и заменяя типы, которые вы сериализуете суррогатами.

Для JavaScriptSerializer вы должны предоставить конструктор без параметров, если вы планируете десериализацию объектов из json-строки.

Для меня я обычно использую JavaScriptSerializer в логике представления, где есть простая модель, которую я хочу отобразить в Json вместе со страницей без дополнительных запросов ajax. И мне даже обычно не нужно десериализовать их обратно на С#, поэтому никаких накладных расходов вообще нет. Но если это логика сохранения, где я хочу сохранить объекты в хранилище данных (обычно это не-sql-хранилище), чтобы загрузить их позже, я предпочитаю использовать DataContractJsonSerializer, потому что накладные расходы на размещение атрибутов имеют большую гибкость в сериализации/десериализации настройка процесса, особенно когда дело доходит до загрузки сериализованных данных в объекты более новой версии, с обновленными определениями

Ответ 3

Лично я считаю, что DataContractJsonSerializer пахнет чрезмерной инженерией. Я пропустил его и перешел с JavaScriptSerializer. В случае, если JavaScriptSerializer недоступен, вы можете использовать FridayThe13th (библиотека, которую я написал; p).