web services - consumir - Cómo pasar valores enumerados a un servicio web
consumir servicio soap c# (8)
Mi dilema es, básicamente, cómo compartir una enumeración entre dos aplicaciones.
Los usuarios cargan documentos a través de una aplicación de front-end que está en la web. Esta aplicación llama a un servicio web de la aplicación de back-end y le pasa el documento. La aplicación de fondo guarda el documento e inserta una fila en la tabla de documento .
El tipo de documento (7 tipos de documentos posibles: Factura , Contrato , etc.) se pasa como un parámetro al método UploadDocument del servicio web. La pregunta es, ¿cuál debería ser el tipo (y los valores posibles) de este parámetro?
Como necesita codificar estos valores en ambas aplicaciones, creo que está bien utilizar una cadena descriptiva ( Factura , Contrato , Orden de trabajo , Obra firmada ).
¿Es tal vez un mejor enfoque para crear una enumeración DocumentTypes en la primera aplicación, y para reproducirla también en la segunda aplicación, y luego pasar el valor entero correspondiente al servicio web entre ellos?
Solo puedo hablar sobre .net, pero si tienes un servicio web ASP.net, deberías poder agregar una enumeración directamente a él.
Cuando utilice la "Agregar referencia web" en su aplicación cliente, la clase resultante debe incluir esa enumeración
Pero esto es muy fuerte, estoy bastante seguro de haberlo hecho en el pasado, pero no puedo decirlo con certeza.
Sugeriría que no se pase un número entero entre ellos, simplemente por motivos de legibilidad y depuración. Digamos que está revisando sus registros y ve un montón de 500 errores para DocumentType = 4. Ahora debe buscar qué DocumentType es 4. O si una de las aplicaciones se refiere a un número que no existe en la otra, tal vez debido a versiones no coincidentes.
Es un poco más de código, y frota un poco la parte estática de tipeo del cerebro, pero en los protocolos en la parte superior de HTTP, la sabiduría recibida es alinearse con cadenas legibles sobre enumeraciones opacas.
En .NET, los valores de enumeración se serializan (por defecto) en xml con el nombre. Para las instancias donde puede tener múltiples valores ( banderas ), coloca un espacio entre los valores. Esto funciona porque la enumeración no contiene espacios, por lo que puede obtener el valor de nuevo dividiendo la cadena (es decir, "Contrato de factura SignedWorkOrder", utilizando el ejemplo de lubos).
Puede controlar la serialización de los valores de los servicios web en asp.net utilizando XmlEnumAttribute , o utilizando el atributo EnumMember al usar WCF.
Si está consumiendo su servicio web desde una página / aplicación .NET, debería poder acceder a la enumeración después de agregar su referencia web al proyecto que está consumiendo el servicio.
Todavía usaría la enumeración internamente, pero esperaría que los consumidores me pasaran solo el nombre, no el valor numérico en sí.
solo un ejemplo tonto para ilustrar:
public enum DocumentType
{
Invoice,
Contract,
WorkOrder,
SignedWorkOrder
}
[WebMethod]
public void UploadDocument(string type, byte[] data)
{
DocumentType docType = (DocumentType)Enum.Parse(typeof(DocumentType), type);
}
Me he dado cuenta de que al utilizar "Agregar referencia de servicio" en lugar de "Agregar referencia web" de VS.net, los valores de la enumeración reales aparecen, así como los nombres de las enumeraciones. Esto es realmente molesto ya que necesito admitir clientes 2.0 y 3.5. ¡Termino teniendo que entrar en el código proxy del servicio web generado 2.0 y agregar manualmente los valores enum cada vez que hago un cambio!
Si no está trabajando con .NET para .NET SOAP, aún puede definir un enumerador siempre que ambos puntos finales estén usando WSDL.
<s:simpleType name="MyEnum">
<s:restriction base="s:string">
<s:enumeration value="Wow"/>
<s:enumeration value="This"/>
<s:enumeration value="Is"/>
<s:enumeration value="Really"/>
<s:enumeration value="Simple"/>
</s:restriction>
</s:simpleType>
Es hasta WSDL -> Proxy generador herramienta para analizar eso en un equivalente enum en el idioma del cliente.
Hay algunas razones bastante buenas para no usar enum
s en un límite de interfaz como ese. Considera la publicación de Dare sobre el tema.