7
votes

Attribut Datamember WCF pour les champs en lecture seule?

J'essaie de créer une classe avec un champ d'identifiant en lecture seule, mais j'ai des problèmes de conservation de la valeur lorsque l'objet passe dans le serveur WCF.

Je ne peux pas définir le [Datamember] Code> Attribut sur la propriété publique car il n'y a pas de méthode code> SET CODE>, et je voudrais le garder de cette façon, si possible, car je ne veux pas que cette valeur changeait par des moyens externes. Je ne peux pas définir l'attribut [datamember] code> sur le champ privé car il jette une erreur dans les environnements de fiducie partielle. P>

public class MyClass
{
    private int _id;

    public int Id 
    { 
        get { return _id; } 
    }

    private string _otherProperties;

    [DataMember]
    public string OtherProperties
    {
        get { return _otherProperties; } 
        set { _otherProperties = value; }
    }
}

wcf datacontract datamember

1 commentaires

msdn.microsoft.com/en-us/library/ms733127.aspx: Il ne faut pas lancer une erreur si vous avez une méthode privée. Vous pouvez voir dans la note: ce DataContract ne se soucie pas de la visibilité de la méthode.

3 Réponses :

1
votes

Non. Le membre de données doit avoir un getter et un setter pour être sérialisable. Il est responsable de la validation de cet identifiant n'a pas été changé sur le client.

0 commentaires

7
votes

En règle générale, vos classes de contrat de données doivent être des objets de transfert de données très légers sans aucune signification logique ou plus profonde attachée à elles. Juste des conteneurs pour ferry des données sur le nuage. Ils devraient être des cours publiques, avec juste un ensemble de propriétés publiques en lecture-écriture. Dans les classes de votre logique d'entreprise, vous devez les convertir en entités commerciales internes et faire l'inverse lorsque vous transmettez des données.

Ceci sépare le modèle de transfert de données à partir de n'importe quel modèle d'entité interne et garantit une main-d'œuvre optimale, vous permettant d'éviter des problèmes tels que celui que vous êtes confronté - où des problèmes de conception OO en conflit avec le comportement de fonctionnement de la WCF.

Avec de très petits projets, les frais généraux de garder un modèle distinct ne valent pas la peine. Automapper peut vous aider à minimiser la main-d'œuvre manuelle requise.

Parler de votre scénario spécifique, je ne suis pas sûr de comprendre exactement la déclaration de problème. Vous ne voulez pas que certains champs soient modifiés? Mais ce champ ne fait qu'une partie du modèle de données - les parties du modèle de données ne sont jamais "modifiées" - il n'y a pas de données "anciennes", juste des données votre client compose. Votre code client envoie simplement un objet de données au serveur. Si le serveur ne se soucie pas d'un membre de la classe, il devrait simplement l'ignorer.

Ce n'est pas comme des insnaces des objets de données sur le serveur et attendez que les clients les manipulent. Un champ en lecture seule pourrait avoir un sens conceptuellement dans un tel scénario, mais cela n'est pas aussi avec WCF. Le client constitue simplement un objet et l'envoie au serveur. Si vous ne souhaitez pas que le serveur écoute certaines données, ne l'ajoutez pas au modèle de données ou (si peut-être qu'il est parfois nécessaire, uniquement pour des utilisateurs spécifiques ou tels) rendent le serveur l'ignorer quand il n'est pas souhaité. < / p>

2 commentaires

Laissez-moi voir si j'ai ce droit ... vous suggérez que chaque objet doit avoir deux parties: une classe Dataconfer (Datacontract) pour l'envoi / la réception de données sur / à partir du serveur WCF et de la classe actuelle elle-même qui contient la logique commerciale, InotifyPropertyTychanged, fonctionnalité, etc.?

Oui et non. Les objets de transfert de données n'ont pas besoin de mapper un en tête-à-un à tout objet logique commercial. Par exemple, je pourrais avoir un objet métier grand et complexe d'employés, mais sur mes différentes opérations de la WCF, je viens d'exposer les données pertinentes à l'opération particulière. Par exemple. UpdateContacTInfo (GUID EmployedAd, contactInfo Info) ne transporterait que les informations de contact - alors qu'elle pourrait toujours faire partie de mon objet métier d'employé. Pour de petits scénarios, l'objet de transfert de données et l'objet commercial ont tendance à être presque identiques, mais - juste sans aucun champ "indésirable" (par exemple, hachage de mot de passe).

9
votes

Vous pouvez le faire:

public int Id
{
     get;
     private set;
}

0 commentaires