Service Client WCF accès membres internes

Question

j'ai une bibliothèque de service WCF (mis en œuvre à l'aide NH)

avec un de la classe dit test, défini comme

[DataContract] 
public class Test 

avec deux constructeurs définis comme

internal Test() 
    { 

    } 

    public Test(int param1, IList<Int32> param2, int param3) 
    { 
     this.Param1 = param1; 
     this.Param2 = param2; 
     this.Param3 = param3; 
    } 

Maintenant, je veux que mon application client accède uniquement au second constructeur avec des paramètres et non le constructeur par défaut, que j'ai essayé de cacher en utilisant internal.

Mais ce qui se passe réellement est juste en face. Dans l'application cliente, je ne peux voir que le constructeur interne.

Des pensées?

Answer 1

Dans WCF, lorsque vous ajoutez une référence de service, vous obtenez un proxy client - mais pour les données, seulement les données (et pas de comportement) est en cours désérialisée - c'est la seule chose qui est stocké et transporté dans le schéma XML.

Votre proxy client ne peut pas découvrir et utiliser des constructeurs supplémentaires, aucune méthode supplémentaire sur vos objets de contrat de données - strictement seulement la partie de données est transportée sur le réseau. De plus, le standard DataContractSerializer (utilisé par défaut par WCF) n'appelle même pas un constructeur lors de la désérialisation de vos données du message reçu - il n'alloue qu'un segment de mémoire assez grand pour vos données, puis les déplace dans le emplacements de mémoire appropriés. Tout constructeur est ignoré (ce qui explique aussi pourquoi DataContractSerializer ne nécessite pas de constructeur public sans paramètre sur ses classes de données - comme le fait XmlSerializer).

Answer 2

Par défaut, WCF suit l'un des principes fondamentaux de l'orientation du service:

• Services contractuels d'actions, pas de classe

Ce que cela signifie est que lorsque vous créez une référence de service dans Visual Studio, VS demande au service les métadonnées du service. Ce contrat est exprimé en WSDL et XSD et, sur la base du contrat, VS génère automatiquement les classes correspondantes. Ces classes générées automatiquement constituent votre proxy - pas celui que vous avez défini du côté service. Ils peuvent sembler très similaires, mais ce sont des classes complètement différentes. Puisque XSD n'exprime que la structure (et non le comportement), la seule partie de vos contrats de données d'origine qui sont transférés du WSDL au proxy sont les propriétés marquées par [DataMember].

Le constructeur que vous voyez est le constructeur par défaut de la classe générée automatiquement.

Il existe des moyens de partager des classes de données entre le service et le client, mais cela signifie que vous les associez étroitement, ce qui n'est pas recommandé pour la plupart des scénarios.

Answer 3

Nous partageons des contrats (interfaces et membres de données) et non des comportements (méthodes) avec des clients lors de la création de proxies à partir de métadonnées (wsdl).

Si vous avez besoin de partager une sorte de logique de mise en œuvre pour forcer la façon dont les clients interagissent avec votre service, alors vous pourriez envisager:

1. Livrer une dll côté client qui encapsule le proxy de service et applique tout comportement nécessaire (initialisation, ordre des méthodes, etc.).
2. Validation des valeurs du contrat de données lorsque vous le recevez pour vérifier qu'elles se trouvent dans les plages connues.

HTH,

Z