6 maneiras de fazer a mesma coisa, o que é considerado boas práticas?

As vezes tem tantas maneiras diferentes de fazer o mesmo código que nós ficamos na dúvida quanto a qual maneira usar. O que seria considerado "boa prática" pela comunidade e o que sua equipe entenderia melhor. Suponhamos que você esteja trabalhando dentro de um método de um Domain Service chamado UmDomainServiceChique(objetoDoDominio) que será chamado por uma API. Você tem uma regra de negócio chique para ser verificada que por enquanto chamarei de VerificaMinhaRegraChiqueComplexa(). Você chama UmDomainServiceChique(objetoDoDominio) e caso VerificaMinhaRegraChiqueComplexa() retorne true você vai querer que UmDomainServiceChique faça o que tem que fazer e a api retornar Ok 200, caso contrário você quer que a API responda um erro qualquer, tipo BadRequest, e retornar uma mensagem dizendo que VerificaMinhaRegraChiqueComplexa deu ruim. Eu vejo 6 maneiras de fazer isso, gostaria de saber a opinião de outrs devs sobre qual seria a maneira menos gambiarr

Como usar a mesma dll em uma aplicação windows forms e web forms

Recentemente me deparei com a seguinte situação em uma aplicação legada: tinha uma dll com as classes de negócio / aplicação, mas essas dlls faziam, de vez em quando, uso do namespace system.web. 

Meu desafio era utilizar estas classes em uma versão windows forms da aplicação, mas isso era impossível, uma vez que com a presença do namespace system.web a aplicação não compilava, e não era permitido a adição da minha dll. 

Você pode estar pensando, e eu também pensei, que o problema se resolveria facilmente adicionando uma referência à dll system.web.dll, mas se fosse só isso o problema estaria resolvido.

O que realmente me causou esse problema era o fato de que quando você cria novas aplicações windows forms ou console, por padrão o visual studio 2010 usa a versão "client profile" do .net framework, uma versão mais magra que não tem toda aquela parafernalha server. No entanto, minha aplicação fazia muito uso de HttpContext.Current.Session.Add, dentro de system.web.dll, que é justamente uma parafernalha server. 
Consegui resolver esse prodblema trocando o framework para o framework "comum", com isso pude adicionar minha dll e a aplicação até compilava, o que não quer dizer que funcionava. 

Vá em project --> properties e na aba application, mude o target  framework de .net framework 4 client profile para .net framework 4, simplesmente.

Vá em project --> properties e na aba application, veja o target framework

Mude o target framework para .net framework 4


Corrigi o problema na aplicação legada separando em classes que implementam uma mesma interface as partes que usam e que não usam HttpContext, e usei o framework de injeção de dependência/ IoC Unity para instanciar a classe correta dependendo da aplicação ser web ou windows. Mas também dá para resolver sem isso, usando a dll legada mesmo.

Fiz 4 exemplos de minhas possíveis soluções usando workarounds:
Usando portable class library
Usando o class library comum
Usando diretivas de compilação (preprocessor directives)
meu preferido: usando reflection

para ver o meu post no msdn americano

Comentários

Postagens mais visitadas deste blog

Factory Reset do Samsung Galaxy S

erro "ora-12154: tns: não foi possível resolver o identificador de conexão especificado"

Detectar o encoding de um arquivo para não corromper ao transformá-lo