Pregunta

El marco .net se envía con System.runtime.serialization.json.datacontractjsonserializer y System.web.script.serialization.javaScriptSerializer, ambos de/serialize JSON. ¿Cómo sé cuándo elegir uno de estos tipos sobre el otro? MSDN no deja en claro 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 desarrollo principal de cada proyecto. Algunos son simples, dos tienen una lógica compleja con respecto a la producción de tipos administrados de JSON (los tipos no se mapean de cerca con las transmisiones) pero no tienen é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.

¿Fue útil?

Solución

El DataContractJSonserializer está destinado a su uso con aplicaciones de clientes WCF donde los tipos serializados son típicamente clases de POCO con el atributo DataContract aplicado a ellos. Sin contrato de datos, 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 diferentes conjuntos de herramientas, su programa podría ir de lado.

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

Como puede ver por los comentarios, existen muchas opciones para la serialización de Ajax, y para abordar su velocidad frente a las preguntas de mantenimiento, puede valer la pena investigarlas para encontrar una solución que satisfaga las necesidades de todos los equipos, a Reduzca los problemas de mantenimiento a largo plazo a medida que todos hacen las cosas a su manera.

Actualización 2014-04-07: sugiero usar json.net si puede. Ver http://james.newtonking.com/json Comparación de características para una revisión de las 3 bibliotecas consideradas en esta pregunta.

Actualización 2015-05-26: si su empresa requiere el uso de productos con licencia comercialmente, o necesita hasta el último rendimiento, es posible que también desee consultar https://servicestack.net/.

Otros consejos

Ambos hacen aproximadamente lo mismo, pero utilizan una infraestructura muy diferente, aplicando así diferentes restricciones en las clases que desea serializar/deserializar y proporcionar un grado diferente de flexibilidad para ajustar el proceso de serialización/deserialización.

Para DataContractJsonSerializer Debe marcar todas las clases que desea serializar usando DataContract Atrtribute y todos los miembros que usan DataMember atributo. Además de si algunas de ustedes clases tienen miembros de ENUM, entonces los enums también deben marcarse como DataContract y cada miembro de Enum - con EnumMember atributo. También DataContractJsonSerializer Le permite un control fino sobre todo el proceso de serialización/deserialización al alterar la lógica de resolución de los tipos y reemplazar los tipos que serializa con los sustitutos.

Para JavaScriptSerializer Debe proporcionar un constructor sin parámetros si planea deserializar objetos de la cadena JSON.

Para mi, normalmente uso JavaScriptSerializer En la lógica de presentación, donde hay un modelo simple que quiero renderizar en JSON junto con Page, sin solicitudes adicionales de AJAX. Y por lo general, no tengo que deserializarlos a C#, por lo que no hay sobrecarga en absoluto. Pero si es lógica de persistencia, donde quiero guardar objetos en un almacén de datos (generalmente almacenamiento sin SQL), para cargarlos más tarde, prefiero usar DataContractJsonSerializer Debido a que la sobrecarga de los atributos de poner los atributos tiene una flexibilidad en el ajuste del proceso de serialización/deserialización, especialmente cuando se trata de la carga de datos serializados en los objetos de la versión más reciente, con definiciones actualizadas

Personalmente pienso que DataContractJsonSerializer apesta a sobreingeniería. Lo saltaría y iría con JavaScriptSerializer. En el evento donde JavaScriptSerializer no está disponible, puede usar Viernes 13 (una biblioteca que escribí; p).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top