Discussion :

[CypherX]

Bonjour à tous,

Cela fait déjà plusieurs jours que je me demande quel type de contrat entre Data contract ou Message contract est le plus adapté à mon utilisation. Je tiens à signaler que je suis encore novice avec WCF .

A priori le Message contract ne serai pas ce que je veux, car je n'ai pas besoin d'agir sur le corp/en-tête du message SOAP, mais cela permet d'avoir un système de requête réponse qui apporte une certaine souplesse en cas de modifications:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[MessageContract]
public class CustomerRequest
{
   [MessageBodyMember]
   public int Id;
}
 
[MessageContract]
public class CustomerResponse
{
   [MessageBodyMember]
   public int Id;
 
   [MessageBodyMember]
   public string Name;
}
 
[ServiceContract]
public interface ICustomer
{
   [OperationContract]
   public CustomerResponse GetCustomer(CustomerRequest request);
}

En fait la vrai question est de savoir si je peux utiliser des objets DTO pour garder la souplesse du code ci dessus, ou bien cela n'est pas recommandé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
[DataContract]
public class CustomerRequest
{
   [DataMember]
   public int Id;
}
 
[DataContract]
public class CustomerResponse
{
   [DataMember]
   public int Id;
 
   [DataMember]
   public string Name;
}
 
[ServiceContract]
public interface ICustomer
{
   [OperationContract]
   public CustomerResponse GetCustomer(CustomerRequest request);
}

Dans le cas ou je pourrai utiliser le data contract et que je ne souhaite pas de paramètre entrant, vaut t'il quand même mieux mettre CustomerRequest, quitte a ce qu'il ne soit pas utile ?

Au final je cherche une bonne pratique pour avoir de la souplesse et de la simplicité.

Merci de me conseiller, je m'arrache les cheveux

[gdkenny]

mais cela permet d'avoir un système de requête réponse qui apporte une certaine souplesse en cas de modifications

Tu pourrais détailler ce point?

Je peux me tromper mais l'utilisation de MessageContract ne me semble pas approprié à ton cas.

MessageContract doit marquer les classes quand il y a un besoin d'interopérabilité,ou de passage de stream en paramètre au service
(il y a d'autres raisons, mais ces deux la me semble les plus récurrentes)

Dans le cas ou je pourrai utiliser le data contract et que je ne souhaite pas de paramètre entrant, vaut t'il quand même mieux mettre CustomerRequest, quitte a ce qu'il ne soit pas utile ?

J'aurais fait comme ça... Mieux vaut limiter le nombre de méthodes exposées à ton client.

[CypherX]

Concernant la souplesse je voulais dire par la (facilité des gestion de versions). En effet si l 'on prend le premier exemple, le paramètre entrant CustomerRequest permet le jour ou je veux avoir un autre paramètre, de de juste modifier cette classe en lui ajoutant une nouvelle property (non requise), sans toucher à la signature de la méthode.

Mais il semble que cela soit tout à fait faisable sans message contract.

J'aurais fait comme ça... Mieux vaut limiter le nombre de méthodes exposées à ton client.

Juste pour être sur de comprendre, quand tu dis plus de méthodes exposées, tu veux parler des deux classes supplémentaires (CustomerRequest, CustomerResponse) ?

En faite dois je utiliser des DTO dans tous les cas ? Par exemple j'ai une méthode GetCustomer avec en paramètre entrant un integer, dois je créer une classe DTO "GetCustomerRequest" qui sera le paramètre entrant ou juste mettre un paramètre entrant de type integer ? Et que faire si je n'est pas de paramètre entrant, dois je mettre 'GetCustomerRequest" qui ne sera pas utilisé pour ne pas modifier la signature par la suite ?

Merci de ton aide

[gdkenny]

Juste pour être sur de comprendre, quand tu dis plus de méthodes exposées, tu veux parler des deux classes supplémentaires (CustomerRequest, CustomerResponse) ?

Je veux dire qu'il vaut mieux que ton service expose le moins de méthodes possible (les méthodes marquées par [OperationContract]), d'ou ma réponse positive à ta question :

Dans le cas ou je pourrai utiliser le data contract et que je ne souhaite pas de paramètre entrant, vaut t'il quand même mieux mettre CustomerRequest, quitte a ce qu'il ne soit pas utile ?

Dans un service, ce n'est pas adroit de créer des surcharges pour gérer des différences de paramètres (enfin c'est mon avis), surtout pour ton cas.

En fait dois je utiliser des DTO dans tous les cas

Bof, j'ai envie de dire non, à moins que tu ai une contrainte d'interopérabilité ou autre.
Ca marchera aussi bien avec ton entier en argument. C'est pas la peine de faire des DTO juste pour faire des DTO

Effectivement, passer par des DTO t'évitera de changer la signature de tes méthodes exposées si des paramètres sont ajoutés/supprimés, mais dans ce cas, tu devra modifier tes classes DTO, l'implémentation de ton service, et regénérer le proxy (pour communiquer les nouveaux DTO à ton client).
Alors bon, je suis pas convaincu du gain au vu des méthodes que tu donnes en exemple

Tu peux avoir un service qui expose des méthodes qui prennent des DTO en paramètres(tes méthodes les plus "métier"), et d'autres qui prennent des types de base en paramètres.

[CypherX]

Merci, j'avais besoin d'une confirmation et tu me l'as donnée