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…

Tudo o que você precisa saber sobre CORS

Primeiro de tudo, a documentação: http://www.w3.org/TR/cors/
Segundo, como configurar no IIS 7: http://i-liger.com/article/cross-domain-http-request
Como configurar cors no IIS 6: http://enable-cors.org/server_iis6.html
É importante salientar que essa configuração também é possível via web.config. Como o web.config é hierárquico, hereditário e combinatório, então você pode colocar um web.config adicional pequenininho com cabeçalhos só para permitir CORS nas páginas de um diretório, em vez da aplicação inteira.
Se a configuração não for para a aplicação inteira nem para uma pasta inteira temos que colcoar cabeçalhos http na página. Os cabeçalhos são:
  • Access-Control-Allow-Origin -> indica quais domínios podem fazer um request no seu, colocando * permite todos os domínios.
  • Access-Control-Allow-Methods -> indica quais métodos são permitidos o cliente consultar no seu domínio. Não adianta colocar só post ou get, pois o client pode mandar uma requisição head para saber encoding e contenttype antes, ou uma requisição options, para saber mais configurações (é o browser / javascript que manda esses métodos), portanto, permita GET, POST, PUT, DELETE, HEAD, DEBUG, OPTIONS
  • Access-Control-Allow-Headers -> indica quais headers o client pode solicitar, configurar Content-Type, Accept
  • Access-Control-Max-Age -> indica quantos segundos um request já atendido deveria ser mantido em cache. Muita gente coloca 1728000, mas eu acho isso muito tempo. 72000 (20 horas) é um número muito mais aceitável, considerando que mesmo um conteúdo estático como o de um e-learning pode mudar de um dia para o outro.
Um exemplo de web.config para um único diretório é:

    
        
            
                
                
                
                                                               
            
        
    


Também é possível fazer isso em uma única página, colocando, como primeiro código a ser executado no page_load, o código
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, HEAD, DEBUG, OPTIONS");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "72000");
As configurações no IIS valem para todas as páginas, enquanto que as configurações via web.config são para um diretório e o código acima para uma única página. Todos eles representam a mesma configuração.
Mais informações e exemplos: http://encosia.com/using-cors-to-access-asp-net-services-across-domains/

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