DataContract vs XmlType

Question

Dans le cadre de la tentative d'apprentissage WCF, je suis en train de lire sur la sérialisation. J'ai du mal à comprendre comment je peux contrôler la sérialisation dans .NET 3.5. Par exemple, j'ai une classe simple avec quelques propriétés publiques. En ajoutant l'attribut DataContract à cette classe, je peux par exemple contrôler l'espace de noms et le nom de la classe telle qu'elle est sérialisée. D'autre part, je pourrais ajouter l'attribut Serializable (probablement même pas nécessaire) et un attribut XmlType, ce qui me permet également de contrôler l'espace de noms et le nom utilisé pour sérialiser la classe.

J'ai implémenté les deux approches et utilisé la classe dans un contrat de service dans le cadre d'un appel d'interface. J'utilise ensuite un analyseur Http pour voir comment les différents objets sont sérizalized et j'ai remarqué que le XmlType n'a pas influencé le xml dans le http du tout.

J'ai essayé de comprendre cela toute la journée. Qu'est-ce que je rate?

Mise à jour: Je comprends la différence entre les deux et pourquoi ils sont là. Je ne comprends tout simplement pas pourquoi je ne peux pas influencer le fichier XML généré avec XmlType ou (juste essayé XmlRoot).

Fondamentalement, vous pouvez contrôler tous les détails de la sérialisation en implémentant IXmlSerializable, à l'exception des espaces de noms et du nom de l'élément de premier niveau. Pour cela, je supposais que vous auriez besoin de l'attribut XmlType ou XmlRoot. Avais-je tort?

Answer 1

Voir XmlSerializer vs DataContractSerializer: Serialization in Wcf.

Modifier:

Voir Customize your .NET object XML serialization with .NET XML attributes. Obtenez vos données pour sérialiser dans le formulaire que vous voulez d'abord. Ensuite, mettez l'attribut XmlSerializerFormat.

[ServiceContract] 
[XmlSerializerFormat] 
public interface MyService 
{ 
    [OperationContract] 
    [XmlSerializerFormat] 
    void MyMethod(); 
} 

Answer 2

Le principal point de DataContractSerializer est de pas contrôler les détails de sérialisation. Au lieu de cela, l'idée est de sérialiser vos données dans un formulaire qui peut être utilisé par le plus grand nombre de clients. Au lieu d'être concerné par les détails du schéma, on définit un contrat de données en termes de membres de données à envoyer et à recevoir. C'est une description très abstraite des données. Il est sérialisé dans un format très simple qui reflète la description abstraite. Le XML Serializer ne doit être utilisé que lorsque vous avez absolument besoin d'un contrôle sur les détails du XML à sérialiser ou désérialiser. Lorsque vous n'avez pas besoin d'autant de contrôle, respectez le Sérialiseur de contrat de données.

Answer 3

Bien, il y a beaucoup de comparaisons sur DataContractSerializer vs XmlSerializer.

Je suppose que les principaux points à mon avis sont:

• DataContract est "opt-in" - vous devez ajouter explicitement un attribut [DataMember] à un champ ou une propriété (public, privé, interne ou n'importe quoi) pour sérialiser - si vous n'avez pas, il ne sera pas là.Le XmlSerializer sera juste sérialiser toutes les propriétés publiques

• DataContract vous permet de spécifier un ordre spécifique des éléments de données - XmlSerializer est juste en utilisant l'ordre dans lequel ils apparaissent dans votre code source

• XmlSerializer a besoin d'un public paramètre moins constructeur de votre classe

dans les exemples simples, ces avantages DataContractSerializer peut ne pas sembler beaucoup, vraiment - mais il peut être un avantage dans les grandes applications à grande échelle si votre objet de données ne pas doivent avoir un constructeur public sans paramètre, et que vous n'avez pas besoin de "artificiellement" faire apparaître les éléments comme des propriétés publiques juste pour les inclure dans la sérialisation.

Marc

Answer 4

point de clarification: L'attribut [Serializable] n'a rien à voir avec XmlSerialization. L'attribut [Serializable] concerne l'exécution de Runtime.Serialization. Confus, oui.

Il existe trop de sérialiseurs dans .NET.