Compartilhando tipos entre o serviço e o cliente


Uma questão que sempre é levantada quando falamos de contratos de serviços WCF, refere-se ao compartilhamento dos tipos que são expostos pelo documento WSDL. Para retornar e/ou receber uma instancia de uma classe customizada, basta referenciarmos este tipo em um contrato que, automaticamente, ele já será embutido no documento WSDL. Com isso, ao referenciar o serviço no cliente, uma representação desta classe será criada para que seja possível enviar e/ou receber uma instancia deste objeto complexo.

Durante a referencia (independentemente de qual artefato é utilizado para realizá-la (através da IDE ou utilitário svcutil.exe)), ele olhará para o projeto onde o serviço está sendo referenciado, para determinar se o tipo que o serviço expõe/retorna já existe dentro do mesmo. Caso ele não exista, automaticamente uma classe será criada para representá-la que, obviamente, será baseada no documento WSDL. Essa técnica fornece um baixo acoplamento, assim como já era o caso dos ASP.NET Web Services (ASMX).

Como sabemos, a serialização apenas persiste o estado de um objeto. Isso quer dizer que possíveis métodos e/ou atributos especiais não são propagados através deste processo. Há casos em que se quer compartilhar não somente o estado de um objeto, mas também outras funcionalidades que o mesmo forneça, e que está além das capacidades do processo de serialização.

É neste cenário que o compartilhamento de tipos entra em cena. Isso deve mudar ligeiramente a estrutura das aplicações, ou seja, o tipo a ser compartilhado entre o serviço e o cliente deverá ser isolado em um Assembly (DLL), referenciado pelas duas aplicações. O contrato do serviço agora passará a receber e enviar instancias da classe que está neste Assembly compartilhado e com isso, ao invés de criar uma nova classe para representar o objeto, a IDE (ou o utilitário svcutil.exe) irá fazer o uso deste tipo que, além do estado das propriedades que foram fornecidas pelo serviço, temos todas as possíveis funcionalidades que este objeto fornece. Ao contrário do que vimos acima, esta técnica traz um forte acoplamento entre os envolvidos, bem como já acontecia com o .NET Remoting, obrigando as “duas pontas” serem WCF.

A vantagem do compartilhamento é que a cada nova mudança no contrato, ou melhor, nas propriedades do objeto, não há necessidade de atualizar a referencia do serviço para que ele sincronize o objeto local com o objeto exposto pelo documento WSDL. Se todos os projetos estão dentro da mesma solução, basta uma simples compilação e tudo já estará funcionando. Esse comportamento melhora consideravelmente a produtividade e conveniencia durante o desenvolvimento do serviço e do cliente, enquanto o ponto negativo gira em torno da interoperabilidade e do acoplamento que se tem entre os participantes.

Anúncios

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s