António Cruz

Partilha de Experiências com .NET

My Links

Blog Stats

Archives

Login

WCF Programmer's Toolbox

Enquanto programador, acabei por reunir um conjunto de utilitários e práticas que me permitem maior eficácia no desempenho das minhas tarefas de desenvolvimento, debugging e monitorização de serviços. Neste post vou identificar o conjunto de programas que tenho usado, bem como descrever aquela que penso ser a sua utilidade, de acordo com os objectivos que referi.

1) Svcutil.exe - não uso o Add Service Reference. Se apenas quero gerar um proxy para o serviço, dispenso a verborreia que obtenho quando uso o output.config gerado e dispenso a criação da pasta respectiva na solução. Na maioria dos casos, na configuração só preciso dos elementos ABC (address, binding e contract) e um ou outro parâmetro de tuning, como por exemplo o "maxReceivedMessageSize". Na verdade, considero uma boa prática *não* usar o Add Service Reference. Dito isto, às vezes dá jeito usar a feature como "truque" para obter automaticamente a lista de todos os parâmetros e respectivos valores por default, que por sua vez nem sempre são fáceis de identificar na documentação.

2) Microsoft Fiddler - Para simular clientes POX/REST usando o basicHttpBinding, esta ferramenta serve lindamente. É fácil manipular os headers e o body da mensagem enviada, descompacta a stream da resposta quando esta vem gzipped e mostra a comunicação em raw, isto é, sem formatação, o que às vezes também dá jeito, principalmente para detectar problemas no encoding da stream da resposta.

 3) tcpTrace - Há muitos sniffers de rede (por exemplo, o Ethereal é muito bom), mas esta aplicação serve bem quando só quero mesmo fazer um pedido com alteração mínima da configuração (só mudo o endpoint para ser aquele em que escuta o tcpTrace). Podia usar o SvcConfigEditor.exe e alterar o .config para obter a mesma informação em ficheiros, mas geralmente sou mais rápido a i) alterar o endpoint, ii) lançar o tcpTrace e iii) monitorizar *live* a comunicação.

 4) SoapUI - Entre outras, esta aplicação tem uma funcionalidade que aprecio bastante: dou-lhe um endpoint ou um ficheiro que contenha um WSDL e obtenho a listagem de operações e o respectivo conjunto de sample SOAP requests que posso imediatamente usar para provocar um pedido ao serviço fazendo "Play".

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/antoniocruz]

 

posted on Friday, February 02, 2007 5:27 AM

Feedback

# re: WCF Programmer's Toolbox 2/2/2007 6:42 PM Luis Abreu

Antonio, mais umas perguntas :)
1. em relacao ao 1, tb n uso. prefiro definir as interfaces numa dll e reutiliza-las no cliente (o meu cenario e baseado em servicos q sao consumidos por um windows forms)

a minha pergunta era mais na area das recomendacoes. se nao me engano, o Juval fez um documento de recomendacoes e uma delas era que deviamos apenas usar datamember para membros publicos. ora bem, eu n concordo muito com isto (pq acho q tudo depende do cenario para o qual estamos a trabalhar).

como no meu caso eu distribuo a dll com os objectos e a dll com os servicos, achei por bem anotar os campos da classe em vez das propriedades. isto traz algumas vantagens. por ex, permite-me manter algumas das propriedades como readonly (ex.: ID e Version, q sao usados pelos objectos de acesso a base de dados para efectuar actualizacoes e eliminacoes. as propriedades que expoem estes campos sao read only - decisao certa para o meu cenario - mas como estou a anotar os campos consigo enviar esses valores do cliente para o servidor sem problemas).

o q achas deste tipo de aproximacao neste cenario? parece-me bem, sobretudo pq os clientes trabalham com os meus objectos e assim tenho garantias de q n mudam determinados campos. ja agora, e se tivesse que desenvolver um modelo "aberto" (ie, sem ter controlo sobre o cliente), o q recomendavas (partindo do principio q precisava de garantir determinados pressupostos, como por exemplo, a manutencao de id e campos versions).

obrigado :)

# re: WCF Programmer's Toolbox 2/2/2007 11:50 PM António Cruz

Olá, Luís.

A recomendação do Juval, tal como está nas WCF Best Practices em http://www.idesign.net/idesign/download/IDesign%20WCF%20Coding%20Standard.zip é esta:

"Use DataMemberAttribute on properties *or* read-only public members only".

Anyway, é uma boa pergunta. Na minha opinião e apesar de poderes usar membros readonly, penso ser uma melhor arquitectura criares um façade para as classes de negócio que desejas usar, de modo a expôr apenas o que desejas, isto em vez de confiares num mecanismo interno do CLR que neste caso em nada vai afectar o processo de serialização.

Espero ter ajudado,

António Cruz

Title  
Name  
Url
Box Code
Protected by FormShield
Comments