Trabalho com ASP.net a algum tempo e no decorrer dos trabalhos venho aprendendo muito sobre boas práticas do dia a dia. Como todo desenvolvedor, ao pegar um código antigo, é frequente dizer – “Nossa que código ruim, quem fez? Ops, fui eu.”. Isso acontece porque evoluímos constantemente.
Um amigo postou em seu twitter (http://twitter.com/#!/mariosimaojr) uma lista de boas práticas de programação com ASP.net que achei muito interessante (http://jsprunger.com/asp-net-webforms-best-practices/). O post tem quase 1 ano e meio e mesmo assim seu conteúdo é muito recente. Vejo todos os dias pessoas cometendo os mesmos erros.
Acredito que uma tradução para o Português para os iniciantes é sempre bem vinda para acelerar a aprendizagem. Não quero que deixem de aprender inglês, afinal ótimos materiais estão nessa língua, mas o conteúdo do texto pode evitar problemas e melhorar a performance de aplicações.
[TRADUÇÃO]
Durante o tempo que utilizo ASP.NET tenho coletado uma boa quantidade de boas práticas e tenho tentado impor em meus projetos – a maioria deles são coisas que posso simplificar como experiência de desenvolvimento, soluções comuns de problemas ou dicas que simplesmente vão tornar sua vida mais fácil. A maioria das boas práticas são aplicáveis somente para WebForms, mas outros podem ser aplicáveis para o ASP.NET MVC da mesma forma.
· Não escreva código .NET diretamente na marcação ASPX (a não ser que seja para databinding, como por exemplo o ‘Eval’). Se também tem um code-behind, isto fará com que seu código esteja em mais de um local tornando o código menos gerenciável. Coloque todo o código .NET no code-behind. Coisas podem se tornar complexas e difíceis de debugar muito facilmente quando tem que olhar a execução do código em dois lugares diferentes.
· SessionPageStatePersister pode ser usado em conjunto com o ViewState para manter o estado sem aumentar o tamanho das páginas. Sobrescrevendo o PageStatePersister da página com um novo SessionPageStatePersister vai armazenar todo o ViewState na memória e guardará somente a chave de criptografia do lado do cliente. Isto tornará as páginas menores e com download mais rápido se tiver uma quandida significativa de dados no ViewState por alguma razão, no entanto isso vai aumentar o uso de memória do servidor – então tenha cuidado. Um exemplo de como usar o SessionPageStatePersister pode ser visto abaixo.
public override PageStatePersister GetStatePersister() {
return new SessionPageStatePersister(this);
}
· Crie uma BasePage para que suas páginas possam herdar e reutilizar código entre as páginas. Simples princípios de design de Orientação a Objetos – Se você tem funções comuns entre as páginas, como segurança – coloque em uma classe base e então herde esta classe de System.Web.Page, e herde suas páginas desta classe.
· Crie uma MasterPage para herança do visual. Não utilize includes do lado do servidor. Paginas com muitas diferenças de visual deve usar uma MasterPage diferente. Não utilize uma MaserPage para herança de código.
· Faça uso de Cache do ASP.NET para armazenar informações utilizadas com frequência da sua base de dados. Construa (ou reuse) uma camada genérica de cache que vai envolver o Cache do ASP.NET. Se está carregando a mesma lista da base de dados em um drop down toda vez que a página carrega, você deve estar puxando esta lista do cache com base no quão dinâmicos os dados são.
· Envolva objetos do ViewState com propriedades em suas páginas para evitar enganos na escrita do índice, etc. Por exemplo, você deve ter uma única chave do ViewState para cada propriedade. Veja abaixo:
private int SampleId
{
get
{
return ViewState[“SampleId”] == null ? 0 :
(int)ViewState[“SampleId”];
}
set
{
ViewState[“SampleId”] = value;
}
}
· Evite colocar grandes objetos ou objetos gráficos no ViewState, use principalmente para armazenar Ids ou DTOs muito simples. Esta é a razão que as pessoas dizem que o viewstate é gigante – eles estão armazenando coisas como DataSets no ViewState (terrível ideia). Se você se ater a objetos pequenos e com um número limitado de propriedades ou simplesmente Ids inteiros, seus dados no ViewState não serão demasiadamente grandes e seu ViewState será totalmente viável.
· Envolva a Sessão ASP.NET com uma classe SessionManager para evitar enganos de sintaxe durante o desenvolvimento quando referenciar a sessão. Este é apenas outra forma de diminuir erros simples de desenvolvimento.
· Utilize largamente valores de configuração (applicationSettings [key/value]) no web.config – Envolver o Configuration.ApplicationSettings com uma classe pode ser utilizado para leitura com tipagem forte das configurações sem ter que lembrar as chaves do web.config. Se tem configurações, comportamentos, etc., que precisam ser modificados entre diferentes processos de deploy da aplicação, estes devem ser controlados através de configurações no web.config. Por exemplo, nos frequentemente recebemos pedidos como “Nós queremos o recurso X até o final do mês” – Então construímos, testamos e implantamos a atualização a tempo. Mas, adicione um valor no web.config que controla quando o recurso aparece ou não. Exemplo: FeatureXEnabled=”False”, no dia de ir ao ar simplesmente mude a propriedade para “True”.
· Evite a facilidade de configurar as propriedades de exibição em seus controles, ao invés disso utilize estilos CSS e classes – isto torna o estilo mais gerenciável. Somente uma boa prática geral de desenvolvimento para web.
· Crie UserControls em sua aplicação para reutilizar funcionalidades de tela entre suas páginas. Por exemplo, se um dropdown que contém uma lista de categorias é utilizado em vários lugares no site – crie um controle CategoryPicker que fará o databind por si só quando a página for carregada. Está é minha 1ª boa pratica para economia de tempo, estou surpreso como vejo o mesmo drop down com os mesmos dados utilizado da mesma forma em 20 páginas diferentes – ainda com a mesma lógica de databinding duplicada 20 vezes!
· Utilize propriedades em seus UserControls para configurar coisas como valores padrão, diferentes formas entre as páginas, etc. Proprieadades tipadas podem ser definidas em seu UserControl e pode ser utilizada em sua marcação no ASP.NET utilizando propriedades na classe do UserControl. Esta é uma ótima forma para ter mais velocidade no reuso do seu UserControl – isso, no entanto, leva em uma maior complexidade na lógica do UserControl.
· Faça uso dos controles de validação do ASP.NET para fazer validações simples, ou use o CustomValidator para fazer validações complexas.
· Crie uma página de erro amigável para redirecionar quando uma exceção não gerenciada acontecer no site. Armazene toda exceção que chegar nesta página. O redirecionamento pode acontecer através do evento Page_Error na sua classe PageBase, no evento Application_Error no Global.asax, ou com a seção de gerenciamento de erro no web.config. Basicamente, qualquer método que escolher, tenha certeza que nenhuma exceção não tratada deixe de ser logada.
· Quando trabalha com páginas que utilizam um conjunto de dados muito dinâmico, utilize controle de terceiros como http://www.denisbauer.com/ASPNETControls/DynamicControlsPlaceholder.aspx [free], criado por Denis Bauer para simplificar o código necessário para salvar o estado de controles adicionados dinamicamente entre os postbacks. Este pequeno controle tem salvo incontáveis horas de esforço para criar páginas com UserControls altamente dinâmicos. Pegadinha – se você utiliza delegates para os event handlers no UserControl, tem que reconecta-lo em cada postback, um pouco confuso mas não é um grande problema realmente. Event handlers são somente estado que não são salvos através dos postbacks se utilizar este controle.
· Desligue o ViewState de controles e UserControls que não precisam dele.
[/TRADUÇÃO]
Espero que seja útil.
Juliano Marcon 