¿Cuál es la diferencia entre DataContractJsonSerializer y JavaScriptSerializer?

.NET Framework se envía con System.Runtime.Serialization.Json.DataContractJsonSerializer y System.Web.Script.Serialization.JavaScriptSerializer , los cuales des / serializan JSON. ¿Cómo sé cuándo elegir uno de estos tipos sobre el otro? MSDN no aclara cuáles son sus ventajas relativas.

Tenemos varios proyectos que consumen o emiten JSON, y la clase seleccionada para cada uno hasta ahora ha dependido de la opinión del desarrollador principal de cada proyecto. Algunos son simples, dos tienen una lógica compleja con respecto a la producción de tipos administrados a partir de JSON (los tipos no se asignan de cerca a los flujos) pero no tienen ningún énfasis en la velocidad, uno requiere velocidad. Ninguno interactúa con WCF, al menos a partir de ahora.

Si bien estoy interesado en bibliotecas alternativas, espero que alguien también tenga una respuesta a mi pregunta.

El DataContractJsonSerializer está diseñado para su uso con aplicaciones cliente WCF donde los tipos serializados suelen ser clases POCO con el atributo DataContract aplicado. Sin DataContract, sin serialización. El mecanismo de mapeo de WCF hace que el envío y la recepción sean muy simples, pero solo si su plataforma es homogénea. Si comienza a mezclar en diferentes conjuntos de herramientas, su programa puede ir hacia los lados.

JavaScriptSerializer puede serializar cualquier tipo, incluidos los tipos anónimos (unidireccional), y lo hace de una forma más conforme. Pierde el "automagic" de WCF, pero obtiene más opciones de integración.

Como puede ver en los comentarios, hay muchas opciones para la serialización AJAX, y para abordar sus preguntas de velocidad frente a mantenibilidad, podría valer la pena investigarlas para encontrar una solución que satisfaga las necesidades de todos los equipos, para Reducir los problemas de mantenibilidad a largo plazo, ya que todos hacen las cosas a su manera.

2014-04-07 ACTUALIZACIÓN: sugiero usar JSON.NET si puede. Consulte http://james.newtonking.com/json Feature Comparison para obtener una revisión de las 3 bibliotecas consideradas en esta pregunta.

ACTUALIZACIÓN del 26 de mayo de 2015: si su empresa requiere el uso de productos con licencia comercial, o necesita hasta el último rendimiento, también puede consultar https://servicestack.net/ .

Ambos hacen aproximadamente lo mismo, pero utilizan una infraestructura muy diferente, por lo que aplican diferentes restricciones a las clases que desea serializar / deserializar y brindan un grado diferente de flexibilidad para ajustar el proceso de serialización / deserialización.

Para DataContractJsonSerializerusted debe marcar todas las clases que desea serializar usando DataContractatrtibute y todos los miembros usando DataMemberattribute. Además de si algunas de sus clases tienen miembros de enumeración, las enumeraciones también deben marcarse como DataContracty cada miembro de enumeración, con EnumMemberatributo. También le DataContractJsonSerializerpermite un control preciso sobre todo el proceso de serialización / deserialización alterando la lógica de resolución de tipos y reemplazando los tipos que serializa con sustitutos.

Porque JavaScriptSerializerdebe proporcionar un constructor sin parámetros si planea deserializar objetos de la cadena json.

Para mí, generalmente uso JavaScriptSerializeren la lógica de presentación, donde hay un modelo simple que quiero representar en Json junto con la página, sin solicitudes adicionales de ajax. E incluso normalmente no tengo que deserializarlos de nuevo a c #, por lo que no hay gastos generales. Pero si es lógica de persistencia, donde quiero guardar objetos en un almacén de datos (generalmente sin almacenamiento SQL), para cargarlos más tarde, prefiero usarlo DataContractJsonSerializerporque la sobrecarga de poner atributos vale la pena la flexibilidad en el ajuste del proceso de serialización / deserialización, especialmente cuando se trata de cargar datos serializados en los objetos de la versión más nueva, con definiciones actualizadas

Personalmente, creo que DataContractJsonSerializerhuele a exceso de ingeniería. Me lo saltearía y me iría JavaScriptSerializer. En caso de que JavaScriptSerializerno esté disponible, puede usar FridayThe13th (una biblioteca que escribí; p).