C# DataContractJsonSerializer 和 JavaScriptSerializer 有什么区别？

What's the difference between DataContractJsonSerializer and JavaScriptSerializer?

提问by Justin R.

The .NET Framework ships with System.Runtime.Serialization.Json.DataContractJsonSerializerand System.Web.Script.Serialization.JavaScriptSerializer, both of which de/serialize JSON. How do I know when to choose one of these types over the other? MSDN doesn't make it clear what their relative advantages are.

.NET Framework 附带System.Runtime.Serialization.Json.DataContractJsonSerializer和System.Web.Script.Serialization.JavaScriptSerializer，两者都对 JSON 进行反序列化。我怎么知道何时选择这些类型中的一种而不是另一种？MSDN 没有说明它们的相对优势是什么。

We have several projects that consume or emit JSON, and the class selected for each thus far has depended on the opinion of the primary dev on each project. Some are simple, two have complex logic regarding producing managed types from JSON (the types do not map closely to the streams) but don't have any emphasis on speed, one requires speed. None interact with WCF, at least as of now.

我们有几个使用或发出 JSON 的项目，到目前为止为每个项目选择的类取决于每个项目的主要开发人员的意见。有些很简单，两种在从 JSON 生成托管类型方面具有复杂的逻辑（这些类型不会紧密映射到流），但不强调速度，一种需要速度。至少到目前为止，没有人与 WCF 交互。

While I'm interested in alternative libraries, I am hoping that somebody might have an answer to my question too.

虽然我对替代图书馆感兴趣，但我希望有人也能回答我的问题。

采纳答案by Bahri Gungor

The DataContractJsonSerializer is intended for use with WCF client applications where the serialized types are typically POCO classes with the DataContract attribute applied to them. No DataContract, no serialization. The mapping mechanism of WCF makes the sending and receiving very simple, but only if your platform is homogeneous. If you start mixing in different toolsets, your program might go sideways.

DataContractJsonSerializer 旨在用于 WCF 客户端应用程序，其中序列化类型通常是应用了 DataContract 属性的 POCO 类。没有 DataContract，没有序列化。WCF 的映射机制使发送和接收非常简单，但前提是您的平台是同类的。如果您开始混合使用不同的工具集，您的程序可能会横向运行。

The JavaScriptSerializer can serialize any type, including anonymous types (one way), and does so in a more conformant way. You lose the "automagic" of WCF, but you gain more integration options.

JavaScriptSerializer 可以序列化任何类型，包括匿名类型（一种方式），并且以一种更一致的方式进行。您失去了 WCF 的“自动魔力”，但您获得了更多集成选项。

As you can see by the comments, there are a lot of options out there for AJAX serialization, and to address your speed vs. maintainability questions, it might be worth investigating them to find a solution that meets the needs of all the teams, to reduce maintainability issues in the long term as everybody does things their own way.

正如您从评论中看到的，AJAX 序列化有很多选项，为了解决您的速度与可维护性问题，可能值得研究它们以找到满足所有团队需求的解决方案，以从长远来看，减少可维护性问题，因为每个人都以自己的方式做事。

2014-04-07 UPDATE: I suggest using JSON.NET if you can. See http://james.newtonking.com/jsonFeature Comparison for a review of the 3 libraries considered in this question.

2014-04-07 更新：如果可以，我建议使用 JSON.NET。请参阅http://james.newtonking.com/json功能比较以查看此问题中考虑的 3 个库。

2015-05-26 UPDATE: If your company requires the use of commercially licensable products, or you need every last bit of performance, you may also want to check out https://servicestack.net/.

2015-05-26 更新：如果您的公司需要使用商业许可产品，或者您需要最后一点性能，您可能还想查看https://servicestack.net/。

回答by JP Richardson

Personally, I think that DataContractJsonSerializerreeks of over-engineering. I'd skip it and go with JavaScriptSerializer. In the event where JavaScriptSerializerisn't available, you can use FridayThe13th(a library I wrote ;p).

就个人而言，我认为这DataContractJsonSerializer带有过度设计的味道。我会跳过它并使用JavaScriptSerializer. 如果JavaScriptSerializer不可用，您可以使用FridayThe13th（我编写的库；p）。

回答by achekh

Both do approximately the same but using very different infrastructure thus applying different restrictions on the classes you want to serialize/deserialize and providing different degree of flexibility in tuning the serialization/deserialization process.

两者大致相同，但使用非常不同的基础结构，因此对要序列化/反序列化的类应用不同的限制，并在调整序列化/反序列化过程中提供不同程度的灵活性。

For DataContractJsonSerializeryou must mark all classes you want to serialize using DataContractatrtibute and all members using DataMemberattribute. As well as if some of you classes have enum members, then the enums also must be marked as DataContractand each enum member - with EnumMemberattribute. Also DataContractJsonSerializerallows you fine control over the whole process of serialization/deserialization by altering types resolution logic and replacing the types you serialize with surrogates.

因为DataContractJsonSerializer您必须DataContract使用DataMember属性标记要序列化的所有类，并使用属性标记所有成员。以及如果你们中的一些类有枚举成员，那么枚举也必须标记为DataContract每个枚举成员 - 具有EnumMember属性。还DataContractJsonSerializer允许您通过更改类型解析逻辑并用代理替换序列化的类型来精细控制序列化/反序列化的整个过程。

For JavaScriptSerializeryou must provide parameterless constructor if you plan on deserializing objects from json string.

因为JavaScriptSerializer如果您计划从 json 字符串反序列化对象，则必须提供无参数构造函数。

For me, I usually use JavaScriptSerializerin presentation logic, where there's a simple model I want to render in Json together with page, without additional ajax requests. And I even usually don't have to deserialize them back to c# - so there's no overhead at all. But if it's persistence logic, where I want to save objects into a data store (usually no-sql storage), to load them later, I prefer using DataContractJsonSerializerbecause the overhead of putting attributes is worth of flexibility in the serialization/deserialization process tuning, especially when it comes to loading of serialized data into the objects of the newer version, with updated definitions

对我来说，我通常JavaScriptSerializer在表示逻辑中使用，其中有一个简单的模型我想在 Json 中与页面一起呈现，而无需额外的 ajax 请求。而且我什至通常不必将它们反序列化回 c# - 所以根本没有开销。但是如果是持久化逻辑，我想将对象保存到数据存储（通常是 no-sql 存储）中，以便稍后加载它们，我更喜欢使用，DataContractJsonSerializer因为在序列化/反序列化过程调整中，放置属性的开销值得灵活性，特别是在将序列化数据加载到更新版本的对象中时