WCF: exposition des propriétés en lecture seule de DataMember sans set?

Question

J'ai un serveur côté de la classe qui-je mettre à disposition sur le côté client par le biais d'un [DataContract]. Cette classe a un champ en lecture seule qui je tiens à rendre accessibles par l'intermédiaire d'une propriété. Cependant, je suis incapable de le faire car il ne veut pas croire que je me suis permis d'ajouter un [DataMember] propriété sans avoir à la fois get et set.

Donc, existe - il un moyen d'avoir un [DataMember] propriété sans setter?

[DataContract]
class SomeClass
{
    private readonly int _id; 

    public SomeClass() { .. }

    [DataMember]
    public int Id { get { return _id; } }        

    [DataMember]
    public string SomeString { get; set; }
}

Ou sera la solution d'utiliser [DataMember] comme le terrain (comme par exemple montré ici)? A essayé de faire cela, mais il ne semble pas de soins, le champ est en lecture seule..?

Edit: c'Est la seule façon de faire une propriété en lecture seule par le piratage comme ça? (pas - je ne veux pas le faire...)

[DataMember]
public int Id
{
    get { return _id; }
    private set { /* NOOP */ }
}

Answer 1

Votre "côté serveur" de la classe à ne pas être "disponible" pour le client, vraiment.

Voilà ce qui se passe: sur la base des données du contrat, le client va créer une nouvelle classe à partir du schéma XML du service. Il ne peut pas utiliser le serveur-côté de la classe en soi!

Il sera re-créer une nouvelle classe à partir de la définition de schéma XML, mais ce schéma ne contiennent pas de de la .NET choses spécifiques comme la visibilité ou des modificateurs d'accès - c'est juste un schéma XML, après tout. La classe côté client sera créé d'une façon telle qu'il a le même "empreinte" sur le fil - par exemple, il sérialise dans le même format XML, dans le fond.

Vous ne peut pas "transport" .NET des savoir-faire spécifiques de la classe par le biais d'un SAVON à base de service - après tout, tout, vous êtes de passage autour sont sérialisés messages - pas de cours!

Cochez la case "Quatre principes de la SOA" (défini par Don Box de Microsoft):

1. Les limites sont explicites
2. Les Services sont autonomes
3. Les Services de partage de schéma et de contrat, pas de classe
4. Comptabilité est fondée sur la politique

Voir le point #3 - services de partage de schéma et de contrat, pas de classe - vous ne jamais partager l'interface et le schéma XML pour les données du contrat - c'est tout - pas de .NET classes.

Answer 2

mettre l'attribut DataMember sur un champ et non sur la propriété.

N'oubliez pas que la WCF ne connaît pas l'encapsulation. L'encapsulation est un terme POO, pas un terme SOA.

Cela dit, rappelez-vous que le champ sera accessible en lecture seule aux personnes utilisant votre classe. Toute personne utilisant le service aura un accès complet au champ de son côté.

Answer 3

J'avais des propriétés dans une classe de ma couche de service que je voulais transmettre à Silverlight. Je ne voulais pas créer une toute nouvelle classe.

Pas vraiment "recommandé", mais cela semblait être le moindre des deux maux qui passaient par-dessus la propriété Total de silverlight (uniquement pour la liaison de données visuelle).

 public class PricingSummary
{
    public int TotalItemCount { get; set; } // doesnt ideally belong here but used by top bar when out of store area

    public decimal SubTotal { get; set; }
    public decimal? Taxes { get; set; }
    public decimal Discount { get; set; }
    public decimal? ShippingTotal { get; set; }
    public decimal Total
    {
        get
        {
            return + SubTotal
                   + (ShippingTotal ?? 0)
                   + (Taxes ?? 0)
                   - Discount;
        }
        set
        {
            throw new ApplicationException("Cannot be set");
        }
    }
}
 

Answer 4

Définir le contrat de service (interface) Avant de mettre en œuvre le contrat à l'aide de la classe.