c# - generate - Objetos grandes y complejos como resultado del servicio web
params comments c# (4)
Hola otra vez señoras y caballeros!
OK, siguiendo mi otra pregunta sobre los resultados del servicio web ASP.NET, las clases de proxy y la conversión de tipos . Llegué a una parte en mi proyecto donde necesito ponerme a pensar.
Básicamente, tenemos un objeto personalizado grande y complejo que debe devolverse desde un servicio web y consumirse en la aplicación cliente.
Ahora, en base a la discusión anterior, sabemos que esto tomará la forma de la (s) clase (s) de proxy como el tipo de devolución. Para superar esto, necesitamos básicamente copiar las propiedades de una a la otra.
¡En este caso, eso es algo que realmente, realmente, realmente! me gusta evitar!
Entonces, me hizo pensar, ¿de qué otra manera podríamos hacer esto?
Mis pensamientos actuales son habilitar el objeto para la serialización completa en XML y luego devolver el XML como una cadena desde el servicio web. Luego deserializamos en el cliente. Esto significará un poco de decoración de atributos, pero al menos el código en ambos puntos finales será ligero, es decir, solo con el .NET XML Serializer.
¿Cuáles son sus pensamientos sobre esto?
La serialización .Net XML (de) está muy bien implementada. Al principio pensé, no creo que esto sea una mala idea.
Si las dos aplicaciones importan la (s) misma (s) definición (es) de clases C #, entonces esta es una forma relativamente agradable de obtener el comportamiento de copiado-constructor de forma gratuita. Si la estructura de clase cambia, todo funcionará cuando ambos lados obtengan la nueva definición de clase, sin necesidad de realizar ningún cambio adicional en el lado de consumo / construcción del servicio web.
Hay una ligera sobrecarga en la ordenación y desasociación del XML, pero eso probablemente esté afectado por la sobrecarga de la llamada del servicio web remoto. La mayoría de los programadores entienden bien la serialización .Net XML y deberían producir una solución fácil de mantener.
Rob, al mirar tu otra pregunta tan bien como esta, suena como la situación exacta que tenemos en nuestro entorno. Sin embargo, lo que hemos hecho es alejarnos de los servicios web ASP.Net a los servicios web de WCF y en el proceso hemos resuelto (en su mayor parte) este problema.
Si existe la posibilidad de que su servicio web se pueda implementar como un servicio web de WCF, esto podría funcionar para usted también. Debo mencionar que, al mismo tiempo, hemos mantenido la compatibilidad con versiones anteriores de algunas aplicaciones cliente que necesitan el "estilo de servicio web ASP.Net" de implementación mediante el uso del enlace basichttp de WCF para el transporte del servicio. El resultado final es que nuestras aplicaciones cliente "más nuevas" pueden usar nuestros objetos comerciales reales (a través de referencias a un ensamblaje que contiene solo estos objetos compartidos) como los tipos de devolución de las llamadas al servicio web, ya que realizan llamadas WCF reales.
Hacemos esto al no utilizar las clases proxy autogeneradas y construir nuestro propio canal de cliente para comunicarnos con el servicio WCF.
Si puede usar WCF, avíseme que puedo publicar información adicional.
Ayer obtuve excelentes respuestas sobre un tema muy similar que podría ser útil para usted:
Estoy amando a JSON por este tipo de cosas. Acabo de terminar un portal de tipo POC drop-things para mi empresa que utiliza jQuery para contactarme con servicios web con el servicio de scripts habilitado. Los mensajes son livianos y el análisis, etc. se maneja bastante. Las cosas de jQuery ajax que leí estaban aquí (¡me encanta!): Artículo de jquery ajax