Arquivos da categoria: SOA

soapUI (ou xml string): como enviar valor nulo?

Acrescente no seu cabeçalho:

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”

e na sua tag:

xsi:nil=”true”

E está prontim prontim.

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/" xmlns:privado="http://schemas.datacontract.org/2004/07/PRIVADA">
   <soapenv:Header xsi:nil="true"/>
   <soapenv:Body>
      <tem:Churros>
         <tem:Recheio>
            <privado:Cor xsi:nil="true"/>
         </tem:Recheio>
      </tem:Churros>
   </soapenv:Body>
</soapenv:Envelope>

WCF – Propriedade Specified e serialização

Eu não sou expert em WCF, mas já mexi até que bastante com ele.
Tem uns negocio de serialização dele que se você deixar default o capeta incorpora e você perde o controle.

Eu utilizo o DataContract nos contratos dos serviços para a serialização por simplesmente a lista de tipos suportados ser maior que a do XmlSerializerFormat.

Aí o problema (?) que eu sempre tenho consumindo o serviço de terceiros é: eu adiciono a service reference e vem aqueles mil campos specified para eu setar se eu alterei uma propriedade ou não. Desagradável demais.
Isso acontece porque tem alguns tipos de dados que tem o valor default e coisa e tal, daí para a serialização saber que não é um valor default e que foi setado, é baseado nessa propriedade specified. Corrijam-me se eu estiver falando caquinha.
Setando o DataMember como IsRequired obrigatoriamente o valor sempre tem que vir, então não tem mais a opção de não ter valor setado e o specified morre. Não vejo nenhum problema, inicialmente, em utiliza-lo já que você ainda pode usar o System.Nullable.

[DataContract]
public class Cachorro
{
	[DataMember]
	public string Nome { get; set; }
 
	[DataMember(IsRequired = true)]
	public int? QuantidadeDeFilhotes { get; set; }
}

Usem-o! E facilite a vida do carinha que tá integrando no seu bendito serviço!

AutoMapper – mapeamento chato de objetos

Sabe quando voce tem aquelas quase replicas de classes? Aquele contratinho semi igual a uma classe sua de dominio? Nao deixe de cria-lo por preguica de mapea-los, expor seu objeto de negocio é coisa do capeta.

Ou quando temos um objeto de um legado que muda apenas uma propriedade. Olha esse codigo:

public class ClasseVelha
{
	public decimal Valor { get; set; }
}
 
public class ClasseJuvenil
{
	public int Id { get; set; }
	public decimal Valor { get; set; }
}
 
public ClasseJuvenil Mapear(ClasseVelha velhaco)
{
	AutoMapper.CreateMap<ClasseVelha, ClasseJuvenil>()
			.ForMember(dest => dest.Id, opt => opt.Ignore());
 
	return Mapper.Map<ClasseVelha, ClasseJuvenil>(velhaco);
}

Obs. O codigo acima foi criado no notepad++ e pode conter erros, rs.

O AutoMapper faz todo o trabalho sujo pra gente, e ainda com essa sintaxe lindona. Tem bastante exemplo no GitHub.

Sejam felizes! 🙂

SOA: Second firsts steps ..

Hahaha second firts steps porque já fiz bastante coisa em SOA, mas sou juvenil, sabe quando você nao ENTENDE de verdade o motivo de toda aquela abstração, interfaces e códigos desacoplados bagarai?

Dessa vez eu startei um projeto, no trampo mesmo (meu trampo agora é lindeza! um dia falo sobre ..), que é um refactor de um projeto que fazia consultas em N serviços terceiros e deveria ter possibilidade de integrar mais e mais, e escalar, e ser robusto (isso eu ainda nao entendo, rs), enfim .. projeto de grande porte, que depende de muita coisa que não temos acesso irrestrito, que fosse muito performatico e bem rastreavel. Resolvemos entao modularizar em serviços!

E vou falar uma coisa meio porca, pra definir como funciona a arquitetura de serviço para o pessoal do .NET eu tenho usado o “é um macro da separação de responsabilidade que você faz em class librarys na sua solution” .. e ao meu ver, não é nada mais que isso mesmo (se você fizer direito, claro!).

Interfaces, para não termos contato direto com os serviços: manutenibilidade moleza. Como se comunicam via algum protocolo, podem estar em maquinas diferentes ou em N maquinas o que da uma escalabilidade horizontal motherfucker além da possibilidade de colocar os serviços mais trashs em lugares mais parrudos ou em mais lugares, fazer um load balance, quem sabe. Enfim .. desacoplamento é uma coisa linda, todos deveriam experimentar!

SOA é conteúdo pra caralho! Mas eu queria dar essa review rápida .. mudou minha pog-life. 🙂