Comment transmettre des valeurs énumérées à un service Web

Mon dilemme est, fondamentalement, comment partager une énumération entre deux applications.

Les utilisateurs téléchargent des documents via une application frontale sur le Web. Cette application appelle un service Web de l'application principale et lui transmet le document. L'application principale sauvegarde le document et insère une ligne dans la table Document .

Le type de document (7 types de documents possibles: Facture , Contrat , etc.) est transmis en tant que paramètre à la méthode UploadDocument du service Web. La question est, quel devrait être le type (et les valeurs possibles) de ce paramètre?

Puisque vous avez besoin de coder en dur ces valeurs dans les deux applications, je pense que c'est O.K. pour utiliser une chaîne descriptive ( Facture , Contrat , WorkOrder , SignedWorkOrder ).

Est-ce peut-être une meilleure approche pour créer une énumération DocumentTypes dans la première application, et pour la reproduire également dans la deuxième application, puis passer la valeur entière correspondante au service Web entre eux?

0

8 Réponses

Je ne peux parler que de .net, mais si vous avez un Webservice ASP.net, vous devriez pouvoir y ajouter directement une énumération.

Lorsque vous utilisez ensuite "Ajouter une référence Web" dans votre application client, la classe résultante doit inclure cette énumération

Mais c'est du haut de ma tête, je suis sûr que je l'ai fait dans le passé, mais je ne peux pas le dire avec certitude.

0
ajouté
@Dave Web Services encapsule des méthodes, donc s'il n'y a pas de méthodes utilisant un Enum, il n'y a pas de point - à partir d'une perspective de service Web - de le faire référencer. Je recommande de poser une question distincte avec une description de ce que vous voulez faire / pourquoi vous voulez une énumération non référencée.
ajouté l'auteur Michael Stum, source
La 'Ajouter une référence Web' crée des énumérations, mais uniquement celles qui sont référencées dans certaines méthodes. Je peux ajouter manuellement des enums au fichier Reference.cs généré automatiquement et tout fonctionne bien. Peut-être s'agit-il d'une question distincte, mais existe-t-il un moyen d'obtenir le 'Add Web Reference' pour ajouter toutes les énumérations dans un assembly référencé (mais pas utilisé dans le code) sans pirater le fichier Reference.cs manuellement?
ajouté l'auteur Dave M, source

Dans .NET, les valeurs d'énumération sont (par défaut) sérialisées en xml avec le nom. Pour les instances où vous pouvez avoir plusieurs valeurs ( flags ), alors il met un espace entre les valeurs. Cela fonctionne parce que l'énumération ne contient pas d'espaces, de sorte que vous pouvez récupérer la valeur en divisant la chaîne (par exemple, "Invoice Contract SignedWorkOrder", en utilisant l'exemple de lubos).

Vous pouvez contrôler la sérialisation des valeurs de services web asp.net en utilisant la balise XmlEnumAttribute , ou en utilisant la attribut lors de l'utilisation de WCF.

0
ajouté

Si vous consommez votre service Web à partir d'une page / application .NET, vous devriez pouvoir accéder à l'énumération après avoir ajouté votre référence Web au projet qui consomme le service.

0
ajouté

Il y a quelques bonnes raisons de ne pas utiliser enum sur une frontière d'interface comme ça. Considérez le message de Dare sur le sujet.

0
ajouté

J'ai remarqué que lorsque vous utilisez "Add Service Reference" par opposition à "Add Web Reference" de VS.net, les valeurs enum réelles se retrouvent ainsi que les noms enum. C'est vraiment ennuyeux car j'ai besoin de supporter les clients 2.0 et 3.5. Je finis par devoir entrer dans le code de proxy de service Web généré par 2.0 et ajouter manuellement les valeurs d'énumération chaque fois que je fais un changement!

0
ajouté

Si vous ne travaillez pas avec .NET vers .NET SOAP, vous pouvez toujours définir un énumérateur à condition que les deux points de terminaison utilisent WSDL.

    
     
          
          
          
          
          
     

Its up to the WSDL -> Proxy generator tool to parse that into a enum equivalent in the client language.

0
ajouté

J'utiliserais toujours l'énumération en interne, mais je m'attendrais à ce que les consommateurs ne me transmettent que le nom, pas la valeur numérique elle-même.

juste un exemple stupide pour illustrer:

public enum DocumentType
{
  Invoice,
  Contract,
  WorkOrder,
  SignedWorkOrder
}

[WebMethod]
public void UploadDocument(string type, byte[] data)
{
  DocumentType docType = (DocumentType)Enum.Parse(typeof(DocumentType), type);
}
0
ajouté

Je suggère de ne pas passer un entier entre eux, simplement à des fins de lisibilité et de débogage. Dites que vous parcourez vos journaux et que vous voyez un groupe de 500 erreurs pour DocumentType = 4. Maintenant, vous devez aller chercher quel DocumentType est 4. Ou si l'une des applications fait référence à un nombre qui n'existe pas dans l'autre, peut-être en raison de versions incompatibles.

C'est un peu plus de code, et ça frotte un peu la partie statique de la frappe du cerveau, mais dans les protocoles au dessus de HTTP, la sagesse reçue est de se mettre de côté avec des chaînes lisibles sur des énumérations opaques.

0
ajouté