WCF: DataMember attribut sur la propriété par rapport à

Question

membre

Dans WCF, quelle est la différence entre l'application de l'attribut DataMember 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 {...} 
} 

?

Answer 1

En général, vous devriez préférer appliquer l'attribut DataMember sur la propriété plutôt que sur le champ privé. La seule raison d'appliquer l'attribut au champ à la place est si la propriété était en lecture seule (c'est-à-dire qu'elle n'a pas de setter).

Answer 2

En théorie, et aussi longtemps que vous gardez m_SomeValue toujours égal à SomeValue (comme un simple getter/setter), rien. Autre que le nom de la variable exposée par la WCF. (De toute évidence, si vous marquez la variable m_, votre classe de proxy aura également le même nom m_. La classe de proxy générera une propriété publique que vous utilisiez un champ ou une propriété public/protected/interne/private

Cependant Si vous avez une logique spéciale dans vos accesseurs qui peut modifier la valeur renvoyée (ToUpper() par exemple, une chaîne, par exemple), vous obtiendrez alors une valeur différente:

Answer 3

Tant que vous utilisez le marqueur Name, le contrat est identique, que le champ ou la propriété soit utilisé ou non

[DataMember(Name="SomeValue")] 
private int m_SomeValue; 

Cependant, il peut y avoir quelques problèmes d'autorisations d'accès aux membres privés, en particulier sur Silverlight et CF - dans ce cas, je recommanderais d'utiliser la propriété publique en tant que membre de données. En fait, j'aurais tendance à toujours utiliser une propriété sauf si j'avais une très bonne raison ...

Answer 4

Personnellement, je voudrais juste utiliser la propriété et complètement supprimé la variable membre tous ensemble. c'est-à-dire

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

La propriété va inexplicablement créer une variable membre dans les coulisses.

Answer 5

Si vous ajoutez [DataMember] sur private int m_SomeValue, ce membre ne peut pas être sérialisé, il doit donc être ajouté sur public int SomeValue.

[DataMember]
private int m_SomeValue;

SomeValue public int { get {...} ensemble {...}}

le code ci-dessus ne peut être obtenir la valeur dans le client si vous l'utilisez par WCF.

Answer 6

Il existe de bonnes raisons de marquer des champs plutôt que des propriétés comme DataMember.

S'il vous plaît vérifier pour plus de détails: http://blog.walteralmeida.com/2010/05/wcf-and-datacontract-serialization-internals-and-tips-.html

Par ailleurs: ContractSerializers va sérialiser un domaine privé qui a le DataMemberAttribute sur elle que si vous travaillez dans un environnement plein de confiance.Ne fonctionne pas en confiance partielle (consultez le blog ci-dessus pour une solution)

Answer 7

Ce decission dépend de l'utilisation de vous WCF service:

1. Service interne consommée par vous propres systèmes .NET, qui partagent les même modèle de domaine.
2. Service externe consommé par différentes plates-formes, qui ne partagent pas le même modèle de domaine.

Cas 1.

sérialisation - est le processus de l'état persistant de l'objet. L'état de l'objet en C# est représenté par ses champs de données.

Les propriétés de C# sont essentiellement des méthodes qui manipulent l'état de l'objet. Leur utilisation peut entraîner une désérialisation différente de l'état de l'objet, car l'ordre dans lequel les propriétés sont définies peut avoir un impact sur l'état final des données. D'autres facteurs peuvent entraîner une désérialisation incorrecte de l'état, par exemple si method (jeu de propriétés) repose sur un contexte qui change, comme DateTime actuel.

Vous pouvez dire quoi sur l'encapsulation? Je ne veux pas que mon objet soit dans un état invalide, et je dois faire des vérifications de validation, des vérifications d'intégrité de graphique d'objet, etc. Oui, vous devriez, ainsi nous mettons les attributs de DataMember sur des accessoires? Le problème ici est que beaucoup de personnes mélangent deux choses différentes, DTO (objet de transfert de données, contrat WCF) avec l'entité de domaine. Ce dont vous avez besoin, c'est de vous assurer que les données que vous recevez sont exactement les mêmes que celles qui ont été envoyées, puis assurez-vous que vous pouvez construire une entité de domaine valide à partir de ces données. La meilleure façon d'y parvenir est d'utiliser des classes séparées pour les objets DTO et de construire l'entité de domaine à partir d'eux.

Mais la plupart des programmeurs sont paresseux, et ils aiment décorer simplement l'entité de domaine avec les attributs DataMemeber. Dans ce cas, la décision Champ ou Prop dépend de votre logique de validation, si votre logique de validation est enterrée dans les méthodes Set, vous devrez utiliser Props, si elle est externe, vous devrez utiliser Fields et valider votre entité de domaine après désialisation.

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

Aussi, je voudrais 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 en utilisant la réflexion, et vous devrez les rendre privés et utiliser InternalsVisibleToAttribute.

Case 2.

Il est difficile une. L'objectif principal ici est l'interopérabilité. Dans 99,9%, vous aurez des classes DTO séparées dans ce cas et probablement beaucoup de différentes versions pour supporter les anciens clients. Peu importe où vous placez les Attributs DataMembers, car vous utilisez les DTO. Je ne prendrai 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 expérimentés, et ils ne prennent pas la peine de lire SO.