.net - programacion - normalizacion de base de datos pdf

¿Cuál es su método preferido para enviar datos complejos a través de un servicio web?

Question

Es 2008, y todavía estoy desgarrado por este. Así que estoy desarrollando un método web que necesita un tipo complejo pasado y devuelto. Las dos opciones con las que estoy jugando son:

1. Pase y devuelva objetos comerciales reales con datos y comportamiento. Cuando se ejecuta wsdl.exe, creará automáticamente clases de proxy que contengan solo la porción de datos, y estos se convertirán automáticamente desde y hacia mis objetos comerciales reales en el lado del servidor. En el lado del cliente, solo podrán usar el tipo de proxy tonto, y deberán mapearlos en algunos objetos comerciales reales como mejor les parezca. Un gran inconveniente aquí es que si "poseo" tanto el lado del servidor como el del cliente, y quiero usar el mismo conjunto de objetos comerciales reales, puedo encontrarme con ciertos dolores de cabeza con conflictos de nombres, etc. (Dado que los objetos reales y el los proxies se nombran igual).

2. Olvídate de intentar pasar objetos comerciales "reales". En su lugar, solo cree objetos simples DataTransfer que correlacionaré de ida y vuelta a mis objetos comerciales reales manualmente. De todos modos, wsdl.exe todavía los copia a objetos proxy nuevos, pero al menos no me estoy engañando a mí mismo al pensar que los servicios web pueden manejar de forma nativa los objetos con lógica comercial en ellos.

Por cierto, ¿alguien sabe cómo decirle a wsdl.exe que no haga una copia del objeto? ¿No deberíamos poder decirlo, "Oye, usa este tipo existente aquí mismo. No lo copies!"

De todos modos, por el momento me he conformado con el # 2, pero siento curiosidad por lo que piensan. Tengo la sensación de que hay maneras mucho mejores de hacer esto en general, y puede que ni siquiera sea totalmente preciso en todos mis puntos, así que por favor déjenme saber cuáles han sido sus experiencias.

Actualización : descubrí que VS 2008 tiene una opción para reutilizar los tipos existentes al agregar una "Referencia de servicio", en lugar de crear un nuevo tipo idéntico en el archivo proxy. Dulce.

Answer 1

Darren escribió: Haría un híbrido. Yo usaría un objeto como este ...

Idea interesante ... pasar una versión serializada del objeto en lugar del objeto (wsdl-ed) en sí. De alguna manera, me gusta su elegancia, pero de otra manera, parece frustrar el propósito de exponer su servicio web a terceros o socios potenciales o lo que sea. ¿Cómo sabrían qué pasar? ¿Tendrían que depender exclusivamente de la documentación? También pierde algo del aspecto del "cliente heterogéneo", ya que la serialización es muy específica de .Net. No me refiero a ser crítico, solo me pregunto si lo que propones también está destinado a este tipo de casos de uso. Sin embargo, no veo nada de malo en su uso en un entorno cerrado.

Debería mirar en WCF ... Lo he estado evitando, pero tal vez es el momento.

Answer 2

Haría un híbrido. Yo usaría un objeto como este

public class TransferObject
{
    public string Type { get; set; }
    public byte[] Data { get; set; }
}

entonces tengo una pequeña utilidad que serializa un objeto y luego lo comprime.

public static class CompressedSerializer
{
    /// <summary>
    /// Decompresses the specified compressed data.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="compressedData">The compressed data.</param>
    /// <returns></returns>
    public static T Decompress<T>(byte[] compressedData) where T : class
    {
        T result = null;
        using (MemoryStream memory = new MemoryStream())
        {
            memory.Write(compressedData, 0, compressedData.Length);
            memory.Position = 0L;

            using (GZipStream zip= new GZipStream(memory, CompressionMode.Decompress, true))
            {
                zip.Flush();
                var formatter = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
                result = formatter.Deserialize(zip) as T;
            }
        }

        return result;
    }

    /// <summary>
    /// Compresses the specified data.
    /// </summary>
    /// <typeparam name="T"></typeparam>
    /// <param name="data">The data.</param>
    /// <returns></returns>
    public static byte[] Compress<T>(T data)
    {
        byte[] result = null;
        using (MemoryStream memory = new MemoryStream())
        {
            using (GZipStream zip= new GZipStream(memory, CompressionMode.Compress, true))
            {
                var formatter = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
                formatter.Serialize(zip, data);
            }

            result = memory.ToArray();
        }

        return result;
    }
}

Luego, simplemente pasaría el objeto de transferencia que tendría el nombre de tipo. Entonces podrías hacer algo como esto

[WebMethod]
public void ReceiveData(TransferObject data)
{
    Type originType = Type.GetType(data.Type);
    object item = CompressedSerializer.Decompress<object>(data.Data);
}

en este momento, el serializador comprimido usa genéricos para escribir fuertemente, pero puede hacer que un método sea fácil de utilizar en un objeto Type para deserializar usando origenType, todo depende de su implementación.

Espero que esto te dé algunas ideas. Ah, y para responder a su otra pregunta, wsdl.exe no admite la reutilización de tipos, sin embargo, WCF sí lo hace.

Answer 3

oh, claro, solo hago esto cuando soy el consumidor del servicio web o si tienes algún tipo de controlador del que solicitan un objeto y luego manejas la serialización y el envío en lugar de que ellos consuman directamente el servicio web. Pero realmente, si consumen directamente el servicio web, entonces no necesitarían o necesariamente tendrían el ensamblado que tendría el tipo en primer lugar, y deberían usar los objetos que genera wsdl.

Y sí, lo que propongo es muy específico de .NET porque no me gusta usar nada más. La única otra vez que consumo servicios web fuera de .net fue en JavaScript, pero ahora solo uso las respuestas json en lugar de las respuestas de xml webservice :)

Answer 4

también hay un argumento para separar los niveles: tener un conjunto de objetos serializables que pasan al y desde el servicio web y un traductor para mapear y convertir entre ese conjunto y los objetos de negocio (que pueden tener propiedades no adecuadas para pasar sobre el cable)

Es el enfoque preferido por la fábrica de servicios de fábrica de software de servicio web y significa que puede cambiar sus objetos comerciales sin romper la interfaz / contrato del servicio web.