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ística de fazer:1) se Ver…

Testando Ajax requests em seu endereço local com Google Chrome

Daí você faz o seu site muito louco, cheio de coisa, vai testar no Google Chrome e pá, não funciona.
Failed to load resource: the server responded with a status of 500 (Internal Server Error)"The anti-forgery token could not be decrypted. If this application is hosted by a Web Farm or cluster, ensure that all machines are running the same version of ASP.NET Web Pages and that the <machineKey> configuration specifies explicit encryption and validation keys. AutoGenerate cannot be used in a cluster."


Dá uns erros de acesso não autorizado (401) e você desconfia que é a Same Origin Policy, então o que você faz Habilita o CORS no seu server, altera o web.config, ou as configurações do IIS e permite os cross origin requests.

 <httpProtocol>
      <customHeaders>
    

     <add name="Access-Control-Allow-Origin" value="*" />
     <add name="Access-Control-Allow-Headers" value="Origin, X-Requested-With, Content-Type, Accept" />
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
     <add name="Access-Control-Allow-Credentials" value="True" />    
    
      </customHeaders>
    </httpProtocol>

Mas não funciona.

E pior, você testa no IE e funciona, no Edge e funciona. Aí você pensa: "No IE funciona porque o IE é uma merda, não é seguro. Tenho que fazer direito, e vai funcionar!!".

Aí você testa no Firefox e funciona, testa naquele browser mais esquisito que veio num CD que sua vó comprou no Carrefour e funciona. Você percebeu que o problema é só com o chrome????

Aí você fuça em mais uma dezena de foruns e tópicos na internet até perceber que você fez tudo certinho, o problema é o Chrome. Existe um bug reportado no Chrome desde 2010 E AINDA NÃO RESOLVIDO onde o browser do Google simplesmente bloqueia toda e qualquer requisição ajax para localhost, chumbado no código, simplesmente porque é localhost.

Para resolver esse problema você pode acessar seu site (que você está desenvolvendo e testando localmente) pelo endereço 127.0.0.1 [:porta opcional se for diferente de 80] (que é para onde localhost deveria resolver).

Você também pode usar o domínio lvh.me  [:porta opcional se for diferente de 80] que também resolve para o mesmo IP de loopback e todos os subdomínios dele são resolvidos para o mesmo IP.

Aprendi isso enquanto configurava o DotNetNuke 9 (dnn9) no meu IIS Local. O dnn9 tem um menu de configuração e administração lateral (diferente do menu superior do dnn8) que é montado e aberto via requisições ajax. Pelo IE funcionava, pelo chrome dava uns erros esquisitos, como mencionado acima.

Fikdik.

Comentários

Postagens mais visitadas deste blog

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

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

Factory Reset do Samsung Galaxy S