Quelle est la différence entre DataContractJsonSerializer et JavaScriptSerializer?
Le .NET Framework est livré avec System.Runtime.Serialization.Json.DataContractJsonSerializer et System.Web.Script.Serialization.JavaScriptSerializer , tous deux dé/sérialisant JSON. Comment savoir quand choisir l'un de ces types plutôt que l'autre? MSDN ne précise pas quels sont leurs avantages relatifs.
Nous avons plusieurs projets qui consomment ou émettent du JSON, et la classe sélectionnée pour chacun jusqu'à présent a dépendu de l'avis du développeur principal sur chaque projet. Certains sont simples, deux ont une logique complexe concernant la production de types gérés à partir de JSON (les types ne sont pas étroitement liés aux flux) mais ne mettent pas l'accent sur la vitesse, l'un requiert la vitesse. Aucun n'interagit avec WCF, du moins pour l'instant.
Bien que je sois intéressé par les bibliothèques alternatives, j'espère que quelqu'un pourrait aussi avoir une réponse à ma question.
DataContractJsonSerializer est destiné à être utilisé avec les applications clientes WCF où les types sérialisés sont généralement des classes POCO avec l'attribut DataContract qui leur est appliqué. Pas de DataContract, pas de sérialisation. Le mécanisme de mappage de WCF rend l'envoi et la réception très simples, mais uniquement si votre plateforme est homogène. Si vous commencez à mélanger dans différents ensembles d'outils, votre programme peut se déplacer latéralement.
JavaScriptSerializer peut sérialiser n'importe quel type, y compris les types anonymes (à sens unique), et le fait de manière plus conforme. Vous perdez le "automagic" de WCF, mais vous gagnez plus d'options d'intégration.
Comme vous pouvez le voir dans les commentaires, il existe de nombreuses options pour la sérialisation AJAX, et pour répondre à vos questions de vitesse par rapport à la maintenabilité, il peut être utile de les étudier pour trouver une solution qui répond aux besoins de toutes les équipes, pour réduire les problèmes de maintenabilité à long terme car chacun fait les choses à sa façon.
MISE À JOUR 2014-04-07: Je suggère d'utiliser JSON.NET si vous le pouvez. Voir http://james.newtonking.com/json Comparaison des fonctionnalités pour un examen des 3 bibliothèques considérées dans cette question.
2015-05-26 MISE À JOUR: Si votre entreprise nécessite l'utilisation de produits sous licence commerciale, ou si vous avez besoin de toutes les dernières performances, vous pouvez également consulter https://servicestack.net/ .
Les deux font à peu près la même chose mais en utilisant une infrastructure très différente, appliquant ainsi des restrictions différentes sur les classes que vous souhaitez sérialiser/désérialiser et offrant différents degrés de flexibilité dans le réglage du processus de sérialisation/désérialisation.
Pour DataContractJsonSerializer, vous devez marquer toutes les classes que vous souhaitez sérialiser en utilisant DataContract atrtibute et tous les membres en utilisant l'attribut DataMember. De même que si certaines de vos classes ont des membres enum, les énumérations doivent également être marquées comme DataContract et chaque membre enum - avec l'attribut EnumMember. DataContractJsonSerializer vous permet également un contrôle précis sur l'ensemble du processus de sérialisation/désérialisation en modifiant la logique de résolution des types et en remplaçant les types que vous sérialisez par des substituts.
Pour JavaScriptSerializer, vous devez fournir un constructeur sans paramètre si vous prévoyez de désérialiser des objets de la chaîne json.
Pour moi, j'utilise généralement JavaScriptSerializer dans la logique de présentation, où il y a un modèle simple que je veux rendre dans Json avec page, sans demandes ajax supplémentaires. Et je n'ai même généralement pas besoin de les désérialiser en C # - donc il n'y a pas de surcharge du tout. Mais si c'est la logique de persistance, où je veux enregistrer des objets dans un magasin de données (généralement pas de stockage sql), pour les charger plus tard, je préfère utiliser DataContractJsonSerializer parce que la surcharge de la mise d'attributs vaut la flexibilité dans le réglage du processus de sérialisation/désérialisation, en particulier lorsqu'il s'agit de charger des données sérialisées dans les objets de la nouvelle version, avec des définitions mises à jour
Personnellement, je pense que DataContractJsonSerializer pue la suringénierie. Je l'ignorerais et j'irais avec JavaScriptSerializer. Dans le cas où JavaScriptSerializer n'est pas disponible, vous pouvez utiliser FridayThe13th (une bibliothèque que j'ai écrite; p).