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

Dica rápida sobre cache

Para seu site não ficar "preso" nos caches dos browsers e proxies da vida você deve orienta-los a não armazenar cache.

Há varias diretivas a serem colocadas no cabeçalho (head) que podem te ajudar com isso.

Por exemplo:
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">  <!-- diz que não é para ter cache -->
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> <!-- faz a mesma coisa que o acima, mas  é um comando mais antigo, como cada browser entende uma coisa -->
<META HTTP-EQUIV="EXPIRES" CONTENT="0"> <!-- diz que a página expira agora, então se tiver cachê ele será reciclado. -->




Para fazer isso do lado do "code behind", se estiver trabalhando com C#, pode usar as linhas de código:

Response.CacheControl = "no-cache"; //adiciona o meta cachecontrol = no-cache
Response.AddHeader("Pragma", "No-Cache"); //adiciona o meta pragma = no-cache
Response.Cache.SetCacheability(HttpCacheability.NoCache);  //diz que a politica de cache é NoCache
Response.ExpiresAbsolute = DateTime.Now; //diz para o browser que a data de expiração da página é hoje
Response.Expires = -1; //diz para o browser que a expiração do cache é imediata.


Falando francamente eu não sei a diferença entre todos os vários métodos. Não sei qual funciona para cada browser e qual funciona com servidores de proxy, se é que algum funciona.
O que posso adiantar é que é sempre necessário retirar o cache de páginas de conteúdo dinâmico, conteúdo "logado" ou conteúdo "sensível". O restante pode ser cacheado.


Existe uma diferença sim entre o Expires e o ExpiresAbsolute. Na verdade não é uma diferença de função e sim de conceito. Internamente os dois são idênticos por isso é um desperdício de tempo e até "feio/gambi" usar os dois ao mesmo tempo, pois significam a mesma coisa no final.

A diferença entre as propriedades Response.Expires e a Response.ExpiresAbsolute é que na Expires você diz em quanto tempo a página expira, usando um inteiro. Na ExpiresAbsolute você especifica literalmente "quando" ela expira, na forma DateTime. Omitindo a hora a página expira à meia noite do dia especificado. Omitindo o dia e especificando a hora a página expira todos os dias nesse horário. Não sei o que acontece se não especificar nada. O certo seria expirar todo dia à meia noite, mas aí vai depender de outras regras de cache.

Ou seja, em um você especifica intervalo de tempo/quantidade de minutos. No outro você especifica uma data e hora absolutos.

Por isso não deve usar em conjunto o Response.Expires com o Response.ExpiresAbsolute, pois ambos fazem chamada interna ao método privado Response.Cache.SetExpires e então prevalecerá a hora da última chamada. Isso pode ser visto com a ajuda do Reflector.



Definições da Microsoft



The ExpiresAbsolute property specifies the date and time at which a page cached on a browser expires. If the user returns to the same page before that date and time, the cached version is displayed. If a time is not specified, the page expires at midnight of that day. If a date is not specified, the page expires at the given time on the day that the script runs.
http://msdn.microsoft.com/en-us/library/ms526058(VS.90).aspx


The Expires property specifies the duration of time before a page that is cached on a browser expires. If the user returns to the same page before it expires, the cached version is displayed.
http://msdn.microsoft.com/en-us/library/ms525906(v=vs.90).aspx

Veja aqui: http://www.dotnetspark.com/qa/427-difference-between-responseexpires-and-responseexpiresabsolute.aspx

Além desses comandos de cache temos esses metas que orientam os robôs de indexação e busca o que eles devem fazer: se devem indexar, seguir ou não.

<META NAME="ROBOTS" CONTENT="ALL"> 
<META NAME="ROBOTS" CONTENT="INDEX,NOFOLLOW"> 
<META NAME="ROBOTS" CONTENT="NOINDEX,FOLLOW"> 
<META NAME="ROBOTS" CONTENT="NONE">


E temos este comando especial abaixo para instruir o google bot a não arquivar páginas em seu cache

<META NAME="GOOGLEBOT" CONTENT="NOARCHIVE">


Legal. E como usar tudo isso?
A idéia é que você desenvolva um controle, masterpage ou usercontrol contendo esses controles de cache apenas "APENAS MESMO" para páginas que não podem ser cacheadas de jeito nenhum.
Assim se precisar mudar algo na política geral de cache pode mudar nesses controles e não sair à caça das páginas.

Mas você deve criar um outro controle, usercontrol ou masterpage PARA AS PÁGINAS QUE DEVEM SER CACHEADAS. Assim você pode determinar o tempo e a política de cache para o restante do site.
O site precisa de cache na maioria das páginas, por causa do ganho de velocidade que isso traz.

Páginas com conteúdo "logado" ainda podem ser cacheadas contanto que o conteúdo sensível, como "bom dia nome do usuário" seja atualizado por requisições Ajax assíncronas.

É isso aí, espero que tenha sido útil esse post, depois de tanto tempo sem postar.

Have fun :)

Comentários

Postagens mais visitadas deste blog

Busca de CEP com o Lazarus - Parte 1 - UrlEncode

Botão Add This para adicionar seu post em qualquer rede

Uso de memória no SQL Server