Postagens

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 dar Permissão para o ApplicationPoolIdentity no sistema de arquivos

Imagem
As vezes você está fazendo um website ou sistema web em Asp.Net que precisa ler e gravar um arquivo em uma determinada pasta. Geralmente é uma subpasta do proprio aplicativo. Quando você tenta rodar a aplicação recebe uma mensagem de erro dizendo que a aplicação não tem privilégios para gravar o dito cujo arquivo. Geralmente, quando isso acontecia, eu ia lá nas configurações avançadas do AppPool e trocava o  ApplicationPoolIdentity por NetworkService ou coisa assim, e dava permissão na pasta para o NetworkService . Afinal o AppPool cria um usuário instantâneo para o  ApplicationPoolIdentity  e esse cara não existe no windows, não tem como dar permissão pra ele, certo? Errado. Geralmente o usuário é ApplicationPoolIdentity Muita gente troca para NetworkService Você pode dar permissão para o  ApplicationPoolIdentity  fazendo o seguinte: na hora de escolher o nome do usuário que terá acesso a pasta da sua aplicação (lá no inetpub/wwwroot/SeuApp/ você coloca o nome do

Formatando um item ou membro de enum para texto amigável

Muitas vezes nós criamos Enums para expressar possíveis opções/valores de um campo de múltipla escolha onde os itens são fixos do sistema e não cadastrados em uma tabela. Há casos em que os itens definem regras de negócio e rumos a tomar na aplicação. Nesses casos usar enum não é a melhor opção. Em todos os outros casos usar enum pode ser legal, mas existe um problema: como popular um combo box / dropdown list com os itens do combo com nomes amigáveis? Sim, você não pode colocar espaços e caracteres especiais em um enum. Mas ao popular as opções, seja em uma aplicação windows forms ou web forms, você pode querer mostrar descrições longas e cheias de acentos e caracteres especiais para as opções no dropdown. Você pode usar os atributos Description ou EnumMember para definir programaticamente essas descrições longas, mas obter esses valores de volta vai algumas linhas de código. Nesse código que eu compartilho abaixo escrevi um extension method (não abuse deles) para o tipo enum cham

O absurdo da notação húngara nos dias atuais

Define-se por  notação húngara   a prática de prefixar variáveis com letras que indiquem o seu tipo. Por exemplo i para inteiros, d para datas, f para floats.       As variáveis data de nascimento e nome em notação húngara seriam ddatanascimento e snome, no pior dos casos, ou dDataDeNascimento e sNome se o "programador" resolveu usar camelCase.       Como mencionei nos meus artigos anteriores, e como mencionado nos livros "Código Limpo" e qualquer livro sobre XP, essa prática caiu em desuso.       Ela foi útil um dia para identificar o tipo das variáveis, e de fato identificava. Hoje damos nomes significativos para as variáveis e deixamos que sua declaração e as facilidades da IDE identifiquem o seu tipo. Além disso hoje podemos mudar o tipo de uma variável mantendo o seu nome e o seu uso, coisa que no passado geraria alguma inconsistência semântica na hora de ler e dar manutenção no código.       Soma-se a isso o fato de no passado nã

Modernos padrões de nomenclatura de codificação

     Os padrões apresentados aqui são fruto de uma pesquisa em 2 livros e 4 sites, experiências profissionais do autor, consenso do mercado e recomendações de práticas da Microsoft. Como qualquer convenção ou tecnologia, este não é 100% correto, não é uma verdade absoluta e não é uma bala de prata. São apenas guidelines para que todos nós escrevamos bom código, código limpo e livre de bad smells e que possamos entender e melhorar os códigos uns dos outros, evoluindo como equipe. Nesse texto eu quis expressar não somente regras de nomenclatura e codificação, mas também apresentar algumas boas práticas para um código mais coeso e flexível.      Esses são os padrões que adotamos na empresa onde trabalho e não há nenhum motivo especial para você e sua equipe adotarem este. Os padrões de codificação devem ser um consenso da equipe.      Estes foram elaborados com ajuda de outros padrões prontos de outras empresas, unindo o que eu achei de melhor nos padrões da Microsoft e nas práticas já

Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel - Trobleshooting

Imagem
If you get Could not load type System.ServiceModel.Activation.HttpModule from assembly System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. error trying to access a webservice in .net framework 4.0 or 4.5 it is caused by a conflict between 3.0 and 4.0 version. Fortunately you can fix it in a per application basis. You have only to go to IIS Manager, select your application, double click in modules and delete ServiceModel version 3.0 module.  If you need version 3.0 again or delete 4.0 accidentally you can fix it adding the module again, using the strings below to register the asemblies. ServiceModel - System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 ServiceModel-4.0 - System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 Enjoy :)

Não foi possível carregar o tipo System.ServiceModel.Activation.HttpModule do assembly System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. Como Resolver.

Imagem
Como resolver o erro: Não foi possível carregar o tipo System.ServiceModel.Activation.HttpModule do assembly System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. Alguns recursos / módulos e assemblies do .net causam conflitos entre as versões. Esses conflitos são causados pelo IIS, que "Não sabe" qual a versão correta  do assembly carregar, mesmo se o application pool está configurado com a versão correta. Felizmente essas configurações podem ser corrigidas em cada application no IIS. Esse erro especificamente é causado por um conflito entre as versões 3.0 e 4.0 do assembly ServiceModel. Se sua aplicação é em .net 4.0 ou 4.5 e você obteve este erro ao tentar abrir um webservice vá ao IIS (Painel de controle / Ferramentas Administrativas / Gerenciador do Serviços de Informações da Internet (IIS) ), abra o seu site, de um duplo clique em módulos. Delete o módulo ServiceModel, deixando apenas o ServiceModel-4.0. Caso você