Demande/modèle de réponse dans la mise en œuvre SOA

Question

Dans certains j'ai vu que tous les contrats de services de projets comme l'entreprise (.NET, WCF) acceptent un seul paramètre Request et retour toujours Response:

[DataContract] 
public class CustomerRequest : RequestBase { 
     [DataMember] 
     public long Id { get; set; } 
} 

[DataContract] 
public class CustomerResponse : ResponseBase { 
     [DataMember] 
     public CustomerInfo Customer { get; set; } 
} 

où RequestBase/ResponseBase contiennent des choses communes comme ErrorCode, Context, etc. Les corps des méthodes de service et des proxys sont enveloppés dans try/catch, donc la seule façon de vérifier les erreurs est de regarder ResponseBase.ErrorCode (qui est l'énumération).

Je veux savoir comment cette technique est appelée et pourquoi est-elle meilleure comparée à passer ce qui est nécessaire comme paramètres de méthode et en utilisant les mécanismes de passage/défauts de contexte standard de WCF?

Answer 1

Le motif dont vous parlez est basé sur le développement de Contract First. Il n'est cependant pas nécessaire d'utiliser le modèle de bloc Error dans WCF, vous pouvez toujours renvoyer faultexceptions au client, au lieu d'utiliser le bloc Error Xml. Le bloc Erreur est utilisé depuis très longtemps et par conséquent, beaucoup de gens sont habitués à son utilisation. En outre, d'autres développeurs de plate-forme (java par exemple) ne sont pas aussi familiers avec faultExceptions, même si c'est un standard de l'industrie.
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

Le modèle demande/réponse est très précieuse dans SOA (architecture orientée services), et je vous recommande d'utiliser plutôt que de créer des méthodes qui prennent des paramètres et une valeur passback ou objet. Vous verrez les avantages lorsque vous commencez à créer vos messages. Comme indiqué précédemment, ils ont évolué de Contract First Development, où l'on créait les messages en utilisant d'abord les XSD et générant vos classes en fonction des XSD. Ce processus a été utilisé dans les services Web classiques pour garantir que tous vos types de données se sérialiseraient correctement dans SOAP. Avec l'avènement de WCF, le datacontrerserializer est plus intelligent et sait comment sérialiser des types qui ne se sérialiseraient pas correctement auparavant (par exemple, ArrayLists, List, etc.).

Les avantages de modèle demande-réponse sont:

• Vous pouvez hériter toutes votre demande et les réponses des objets de base où vous pouvez maintenir la cohérence des propriétés communes (bloc d'erreur par exemple).
• Les services Web doivent par nature nécessiter le moins de documentation possible. Ce modèle permet juste cela. Prenons par exemple une méthode comme public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request);. Le client saura par défaut ce qu'il doit transmettre et ce qu'il récupère. De plus, lorsqu'il crée la requête, il peut voir ce qui est requis et ce qui est facultatif. Supposons que cette requête possède des propriétés telles que Carriers [Flag Enum] (Obligatoire), StartDate (Obligatoire), EndDate (Obligatoire), PriceRange (facultatif), MinSeatsAvailable (Option), etc ... vous obtenez le point.
• Lorsque l'utilisateur a reçu la réponse, il peut contenir beaucoup plus de données que l'objet de retour habituel. Bloc d'erreur, suivi des informations, peu importe, utilisez votre imagination.
  Dans l'exemple BusScheduleResponse, cela peut renvoyer plusieurs tableaux d'informations de planification de bus pour plusieurs opérateurs.

Espérons que cela aide.

Un mot de prudence. Ne soyez pas confus et pensez que je parle de générer votre propre [MessageContract] s. Vos demandes et réponses sont DataContracts. Je veux juste m'assurer que je ne vous dérange pas. Personne ne devrait créer ses propres MessageContracts dans la WCF, à moins d'avoir une bonne raison de le faire.