Quel est l'intérêt d'un DataContract dans WCF?

Question

VS.net crée un modèle lorsque vous créez un projet WCF.

Il ajoute une classe au fichier iService1.cs:

 // Use a data contract as illustrated in the sample below to
// add composite types to service operations.
[DataContract]
public class CompositeType
{
    bool boolValue = true;
    string stringValue = "Hello ";

    [DataMember]
    public bool BoolValue
    {
        get { return boolValue; }
        set { boolValue = value; }
    }

    [DataMember]
    public string StringValue
    {
        get { return stringValue; }
        set { stringValue = value; }
    }
}
 

Puisqu'un service WCF peut renvoyer n'importe quelle classe définie par l'utilisateur, pourquoi utiliser une classe DataContract et CompositeType?

Je peux retourner quelque chose comme:

  [OperationContract]
MyUserCollection GetUsers();
 

Qu'est-ce que je rate?

Answer 1

Le DataContract est juste une définition formelle d'un type qui peut être entendu sur les deux côtés du service de la frontière.

Si vous revenez, comme dans votre exemple, un "MyUserCollection" objet, les consommateurs de votre service aura besoin de faire référence à l'intérieur de votre service/système, ce qui est une violation de la SOA principe de limites explicites. À l'aide d'un DataContract, vous publiez la structure de vos types de retour dans un faiblement couplée.

Answer 2

Une autre chose intéressante à noter est que si vous décorez votre code avec DataContract, vous avez beaucoup de contrôle sur ce que le client peut voir et doit renvoyer à votre service. Par exemple:

[DataContract]
public class SampleClass
{
    [DataMember(IsRequired=true)]
    public int MyRequiredProperty { get; set; }

    [DataMember]
    public int MyOptionalProperty { get; set; }

    public int MyInternalProperty { get; set; }
}

Sur l'exemple ci-dessus, vous avez défini lors de la réception de données, vous DEVEZ avoir MyRequiredProperty, et vous pouvez avoir ou de ne pas MyOptionalProperty. Aussi, le client ne verra jamais MyInternalProperty (ce peut être par exemple une propriété qui permet à votre logique interne, mais vous ne voulez pas qu'il soit exposé au niveau du client).

Answer 3

Il y a un autre usage, Vous pouvez modifier le Nom de la classe et de propriétés. C'est une fonctionnalité très pratique lors de la sérialisation et la désérialisation.

[DataContract(Name="EmployeeName")]
public class Person
{
   [DataMember(Name="FullName")]
   public string Name { get; set; }

   [DataMember(Name="HomeAddress")]
   public string Address { get; set; }
}

Answer 4

Je suis en désaccord avec l'affiche qui dit "La DataContract est juste une définition formelle d'un type qui peut être entendu sur les deux côtés du service de la frontière."

Le mot clé ici est "type". Dans .NET, un type est un objet qui peut avoir des champs, des propriétés et des méthodes. Toutefois, lorsque vous décorez une classe avec des DataContract dans votre service WCF, le résultat n'est pas la classe comme par magie transplantées dans le code appelant; non pas par un long shot! Dans le code appelant, vous aurez un "proxy" de la classe. La classe proxy reçoit XML qui représente le contenu du contrat de données. Le code d'appel peut recevoir ces valeurs XML par le biais de la classe de proxy, mais il n'a pas donner le code d'appel de l'accès à l'intérieur de la classe décorer avec des datacontract.

Answer 5

Pour répondre à "marc_s" :

"Si vous en avez .NET sur les deux extrémités de la le fil, c'est très bien. Que faire si vous avoir un client Java appeler votre de service? Si vous mettez vos données à l'intérieur de DataContracts, que l'information est stockées dans le fichier WSDL/XSD métadonnées et peut être utilisé par les clients autres que .NET, trop."

Je pense que c'est faux. Nous allons essayer de faire ceci :

1. Utilisez la valeur par défaut exemple de la WCF projet avec une classe avec DataContract attributs sur les classes et DataMember sur les membres, et un méthode qui renvoie ce type.
2. Construire et afficher le fichier wsdl. Le xsd contient les CompositeType définition. OK.
3. Maintenant, nous allons supprimer tous les attributs DataContract et DataMember
4. Construire et afficher le fichier wsdl. Le xsd contient toujours les ComposityType définition ! (il est plus évident, avec une SCM doux, qui ne montre aucune différence dans les fichiers entre les étapes 2 et 4)

Ainsi, un client Java doit gérer cela, sans DataContract et DataMember ! Je me trompe ou quoi ?