Objetos grandes e complexos como resultado de um serviço da Web [fechado]

Question

Olá novamente, senhoras e senhores!

OK, na sequência da minha outra pergunta sobre Resultados de serviços da Web ASP.NET, classes de proxy e conversão de tipo.Cheguei a uma parte do meu projeto em que preciso colocar meu raciocínio em prática.

Basicamente, temos um objeto personalizado grande e complexo que precisa ser retornado de um Web Service e consumido na aplicação cliente.

Agora, com base na discussão anterior, sabemos que isso assumirá a forma de classe(s) de proxy como tipo de retorno.Para superar isso, precisamos basicamente copiar as propriedades de um para o outro.

Neste caso, isso é algo que eu realmente, realmente, realmente! gostaria de evitar!

Então, isso me fez pensar, de que outra forma poderíamos fazer isso?

Minha ideia atual é habilitar o objeto para serialização completa em XML e então retornar o XML como uma string do serviço da Web.Em seguida, desserializamos no cliente.Isso significará um pouco de decoração de atributos, mas pelo menos o código em ambos os pontos de extremidade será leve, ou seja, usando apenas o .NET XML Serializer.

Quais são seus pensamentos sobre isso?

Answer 1

A (des) serialização .Net XML está muito bem implementada.À primeira vista, não acho que seja uma má ideia.

Se os dois aplicativos importarem a(s) mesma(s) definição(ões) de classe(s) C#, então esta é uma maneira relativamente boa de obter o comportamento do construtor de cópia gratuitamente.Se a estrutura da classe mudar, tudo funcionará quando ambos os lados obtiverem a nova definição de classe, sem a necessidade de fazer alterações adicionais no lado do consumo/construção do serviço web.

Há uma pequena sobrecarga na organização e desempacotamento do XML, mas isso provavelmente é diminuído pela sobrecarga da chamada remota do serviço da Web.A serialização .Net XML é bem compreendida pela maioria dos programadores e deve produzir uma solução fácil de manter.

Answer 2

estou amando JSON para esse tipo de coisa.Acabei de terminar um portal do tipo POC drop-things para minha empresa usando jQuery para entrar em contato com serviços da web com serviço de script ativado.As mensagens são leves e a análise, etc., é bastante controlada.O jQuery ajax coisas que li estavam aqui (adorei!): artigo jquery ajax

Answer 3

Ontem recebi ótimas respostas sobre um tópico muito semelhante que pode ser útil para você:

Comunicação entre javascript e o servidor

Answer 4

Rob, olhando para sua outra pergunta e também para esta, parece a situação exata que temos em nosso ambiente.O que fizemos, no entanto, foi mudar dos serviços web ASP.Net para serviços web WCF e no processo resolvemos (na maior parte) esse problema.

Se houver alguma chance de seu serviço web ser implementado como um serviço web WCF, isso também poderá funcionar para você.Devo mencionar que, ao mesmo tempo, mantivemos compatibilidade retroativa com alguns aplicativos clientes que precisam do "estilo de serviço da Web ASP.Net" de implementação usando a ligação WCF basichttp para o transporte de serviço.O resultado final é que nossos aplicativos clientes "mais recentes" são capazes de usar nossos objetos de negócios reais (através da referência a um assembly contendo apenas esses objetos compartilhados) como tipos de retorno das chamadas de serviço da Web, porque eles fazem chamadas WCF reais.

Fazemos isso não utilizando as classes de proxy geradas automaticamente e construindo nosso próprio canal de cliente para se comunicar com o serviço WCF.

Se você puder usar o WCF, deixe-me saber que posso postar algumas informações adicionais.