La WCF: DataMember l'attribut de la propriété vs membre

Dans wcf, quelle est la différence entre l'application de la DataMember attribut sur une propriété

private int m_SomeValue;

[DataMember]  
public int SomeValue {
  get {...}
  set {...}
}

au lieu d'une variable membre

[DataMember]  
private int m_SomeValue;

public int SomeValue {
  get {...}
  set {...}
}

vous n'avez pas besoin de faire une variable privée d'un membre de données.

InformationsquelleAutor Julien Poulin | 2009-02-17

41

En général, vous devriez favoriser l'application de la DataMember l'attribut de la propriété, plutôt que sur le domaine privé. La seule raison pour appliquer l'attribut dans le champ de la place, c'est si le bien était en lecture seule (c'est à dire qu'il n'a pas de setter).
- Pourquoi avons-nous besoin de le faire si?
- Tous les sérialisation dans WCF dans les deux sens par défaut. Cela signifie que le cadre doit être capable de lire et d'écrire tous les éléments de données. Donc, si vous modifiez un type existant avec des propriétés en lecture seule à être sérialisable, vous pourriez avoir à ajouter les attributs d'un champ. Ce cas est rare, cependant.
- Il est également utile de mettre le DataMemberAttribute sur un champ si votre propriété de lecture/définition a le code susceptible de modifier sa valeur.
- Sauf si cela peut être le comportement prévu.
InformationsquelleAutor dthrasher
24

Aussi longtemps que vous utilisez le Name marqueur, le contrat est identique indépendamment de si le champ ou une propriété est utilisée.
```
[DataMember(Name="SomeValue")]
private int m_SomeValue;
```
Cependant, il peut y avoir quelques problèmes d'autorisations d'accéder aux membres privés, en particulier sur silverlight et CF - dans ce cas, je vous conseille d'utiliser la propriété publique que les données membres. En fait, j'aurais tendance à toujours utiliser une propriété à moins que j'ai eu une très bonne raison...
- Je totalement en désaccord avec vous, Marc, voir mon asnwer, j'aimerais connaître votre réponse sur ce stackoverflow.com/a/8442768/235715
- a répondu comme demandé
InformationsquelleAutor Marc Gravell
6

Il y a de bonnes raisons que vous pouvez pour marquer les champs plutôt que de propriétés DataMember .

Veuillez vérifier ce pour plus de détails : http://blog.walteralmeida.com/2010/05/wcf-and-datacontract-serialization-internals-and-tips-.html

Par la route: ContractSerializers va sérialiser un domaine privé qui a le DataMemberAttribute sur elle seulement si en cours d'exécution dans la confiance totale de l'environnement. Ne fonctionne pas en confiance partielle (consultez le blog énumérés ci-dessus pour une solution)

InformationsquelleAutor Walter Almeida
4

Cette decission dépend de l'usage de vous service WCF:
1. Service interne consommée par vous-même .NET des systèmes, qui partagent le même Modèle de Domaine.
2. De services extérieurs consommés par les différentes plates-formes, qui ne partagent pas le même Modèle de Domaine.
Cas 1.

De sérialisation - est le processus de la persistance de l'état de l'objet. L'état de l'objet en C# est représenté par les champs de données.

Propriétés en C# sont essentiellement des méthodes, qui manipulent l'état de l'objet. Leur utilisation peut entraîner différents état de l'objet après la désérialisation, car l'ordre dans lequel les propriétés sont définies peuvent avoir un impact sur l'état des données. D'autres facteurs peuvent entraîner un état incorrect de la désérialisation trop, si par exemple la méthode (bien réglé) s'appuie sur le contexte qui est en train de changer, comme actuelles DateTime.

Vous pouvez dire ce à propos de l'encapsulation? Je ne veux pas que mon objet pour être en état non valide, et je dois faire des contrôles de validation, le graphe d'objet des vérifications d'intégrité, etc. Oui, vous devez, nous avons donc mis le DataMember attribs sur les accessoires? Pas de.

Le problème ici est que beaucoup de personnes de mélanger deux choses différentes, DTO (Data Transfer Object, WCF Contrat) avec le Domaine de l'Entité. Ce que vous avez besoin est de s'assurer que les données que vous recevez est exectly les mêmes données qui ont été envoyer, puis assurez-vous que vous pouvez construire valide Entité de Domaine à partir de ces données. La meilleure façon d'y parvenir est d'utiliser des classes séparées pour les DTO, et construire Entité de Domaine à partir d'eux.

Mais la plupart des programmeurs sont paresseux, et ils aiment à simple décorer Entité de Domaine avec DataMemeber attributs. Dans ce cas, la décision de Terrain ou des accessoires dépend de l'endroit où votre logique de validation est, si votre logique de validation est enterré dans l'Ensemble des méthodes, vous aurez à utiliser des Accessoires, si c'est extenral vous devez utiliser des Champs et de valider votre Domaine Entité après desirialization.

P. S. je pense que les mêmes règles s'appliquent à tout processus de sérialisation, comme les données de la base de persistnce.

Aussi, je tiens à mentionner que Silverlight ne peut pas sérialiser\désérialiser des champs privés, parce que vous ne pouvez pas y accéder de l'extérieur à l'aide de la réflexion, et vous aurez à les rendre privés et l'utilisation InternalsVisibleToAttribute.

Cas 2.

C'est dur. L'objectif principal ici est l'interopérabilité. Dans 99,9%, vous aurez séparé DTO classes dans ce cas, et probablement beaucoup de versions différentes de la leur à l'appui d'anciens clients. Il n'importe pas où vous mettez DataMembers attribs dans le présent, parce que vous utilisez la DTO de l'. Je ne vais pas la peine d'expliquer ce scénario, parce que les développeurs qui travaillent sur un tel système à grande échelle sont généralement assez connu, et ils ne sont pas la peine de lire DONC.
- Quand il s'agit de la plate-forme liée, type liée à la sérialisation alors oui! les champs ne représentent de l'état. Je pense BinaryFormatter etc ici. Cependant, en termes de interopérables morceau de données, lorsque la réception est de type pas identiques (il pourrait être mex/wsdl généré, ou pourrait être une plate-forme complètement différente), nous devrions avoir aucune connaissance (ou dépendance) les champs. Oui validation reste important, et il existe des mécanismes pour que (et d'autres choses, telles que des rappels).
- En outre; le travail de la sérialisation est pas tout simplement "la persistance de l'état de l'objet" - il est de fait que de la manière qui correspond le protocole. Pour BinaryFormatter, qui signifie (par defualt) "les champs", mais pour WCF... pas tellement. Le données n'est pas m_someValue - le données est SomeValue. m_someValue est un détail d'implémentation. Il y a des façons de gérer la cartographie (comme : à l'aide de Name sur le terrain afin de faire m_someValue apparaissent comme SomeValue)
- Je suis d'accord avec vous sur la partie de l'interopérabilité, je suis en train de penser sur ce sujet, comme un simple procceess de la persistance et de la restauration de l'état, mais il est plus alors que. Ma réponse s'applique en principe uniquement à la situation quand vous avez le C# sur les deux extrémités, et vous réutilisez les mêmes classes. Si nous prenons pour exemple la situation où nous avons un code C# en tant que récepteur et le code PHP que l'expéditeur, puis la situation est un peu différente, j'ai besoin de quelques instants pour réfléchir à ce que je pense que je vais mettre à jour ma réponse.
- La question, cependant, n'est pas "la persistance et la restauration de l'état" - c'est de la WCF. WCF est par la conception et le but une plate-forme neutre, la mise en œuvre d'agnostiques, de la communication, de transport. Même si c'est du C# C#, il est pas nécessaire que la même assemblée est aux deux extrémités; simplement, ils utilisent le même contrat. Et un contrat n'a rien à voir avec les champs.
- Et le contrat n'a rien à voir avec les Propriétés. Il ne s'occupe seulement des éléments XML, et votre DTO représente ce Contrat dans la programmation de l'environnement, et ne devrait avoir aucune logique. Donc, c'est des champs.
- il n'est ni propriétés de ni champs ;p ou les deux! C'est juste à propos de cependant, vous lier votre type de contrat, d'où ma réponse indiquant que l'attribut pourrait être appliquée à avec le même résultat. Re de ne pas avoir de logique; il est plus abstrait que cela, même; il n'est tout simplement pas spécifiquement les champs. Votre choix de la cartographie de la logique de champs est tout simplement une cartographie de détail; la cartographie de propriétés est également tout à fait valable dans presque tous les scénarios (plus que dans les champs, l'OMI - avoir fait un peu de sérialisation de travail).
- Je suppose que nous allons rester, chacun avec son propre avis 🙂
InformationsquelleAutor Alex Burtsev
3

En théorie, et aussi longtemps que vous le garder m_SomeValue toujours égale à SomeValue (comme un simple getter/setter), rien. Autre que le nom de la variable exposés par la WCF. (Évidemment, si vous balisez le m_ variable, alors votre classe proxy sera également le même m_ nom. La classe proxy va générer une propriété publique si vous utilisez un public/protected/interne/domaine privé ou des biens.

Toutefois, si vous avez toute une logique spéciale dans votre accesseurs qui peuvent modifier la valeur retournée (ToUpper()ing une chaîne de caractères, par exemple), alors vous renvoyer une valeur différente.

InformationsquelleAutor Jarrett Meyer
2

Personnellement, je voudrais juste utiliser la propriété et complètement supprimé la variable de membre de l'ensemble. c'est à dire
```
[DataMember]
public int SomeValue
{ get; set; }
```
La propriété inexplicablement créer une variable de membre de derrière les coulisses.
- "inexplicablement"? C'est ce qu'il doit faire. Peut-être que vous avez voulu dire "implicitement"?
- Comment le faire savoir?
- Le compilateur C# génère un privé "sauvegarde" champ de déformation de nom (pour éviter la collision avec le nom de tout autre domaine que vous avez défini) pour l'auto-propriété.
InformationsquelleAutor bj.
1

Si ajouter [DataMember] sur private int m_SomeValue, ce membre ne peut pas être la sérialisation,ce doit être l'ajouter sur public int SomeValue.
```
[DataMember]  
private int m_SomeValue;

public int SomeValue {
  get {...}
  set {...}
}
```
le code ci-dessus peut ne pas être d'obtenir la valeur du client si vous l'utilisez via WCF.
- DataContractSerializers va sérialiser un domaine privé qui a le DataMemberAttribute sur elle.
- Je suis d'accord avec rossisdead, tout domaine privé a DataMemberattribute obtient sérialisés, et est exposée par le service du client.
InformationsquelleAutor shawdren

Vous devez vous connecter pour publier un commentaire.