6 formas de melhorar o vosso código .net
- Eliminar Redundâncias
Antes de colocar qualquer coisa em source control, devemos verificar o código e optimiza-lo, a esta operação chama-se Refactoring. O tempo de manutenção tem como exponencial o numero de vezes que o código está repetido. Das situações mais comuns encontramos, a obtenção de parâmetros vindos de querystring.
Exemplo:
if (Request.QueryString["ClienteID"] == string.Empty)
(...)
int clienteId = int.Parse(Request.QueryString["ClienteID"].ToString());
(...)
if (Request.QueryString["ClienteID"] != string.Empty)
(...)
imaginem que o parâmetro mudou para CustomerID, seria necessário alterar todas as ocorrências de obtenção do parâmetro, para estes casos devemos usar propriedades que traduzam os parâmetros
public int ClienteId
{
get
{
if (!String.IsNullOrEmpty(this.Request.QueryString["ClienteID"]))
{
int result = 0;
if (int.TryParse(this.Request.QueryString["ClienteID"], out result))
{
return result;
}
}
return -1;
}
}
O Refactoring também se aplica ao HTML, ou seja sempre que encontremos um conjunto de controlos que se repetem no markup, devemos criar um User Control.Exemplo: Todos os campos de um formulário contêm uma Label, podemos criar um user control que tem umaTextBox e adicionar-lhe uma label.
Outra forma de optimização de código, está em remover o CSS inline e criar classe para estes estilos.
- Standards
Para alem dos testes unitários, devemos tambem testar as paginas do nosso site com o Javascript desabilitado, e verificar se estas se mantém minimamente coerentes. Apesar de existirem enumeras plataformas de Javascript, tais como JQuery, Mootools, etc, que garantem compatibilidade multi-browser, devemos sempre testar o Javascript em vários browsers e com varias versões. Existem enumeras ferramentas que auxiliam o desenvolvimento Web, das quais eu destaco:
Internet Explorer - IE Developer Toolbar ( disponível no IE8+, versões anteriores é instalado em separado)
Fire Fox - FireBug (extensão instalada á parte)
Google Chrome - Javascript Console (disponível com o browser)
- Controlo de Erros (Error Handling)
Este é outro ponto que é descurado pelos programadores web, e assim surgem as paginas de excepções que exibem a stack do erro e com informação do servidor que pode tornar o site vulnerável a ataques. Para contornar este problema é frequente ser colocado no web.config o redireccionamento para uma pagina de erro.
Exemplo:
<customErrors defaultRedirect="ErrorPage.aspx" mode="On"> <error statusCode="500" redirect="servererror.aspx" /> <error statusCode="404" redirect="filenotfound.aspx" /> <error statusCode="403" redirect="AccessDenied.aspx" /> </customErrors>
Outras soluções para o controlo de erros são:
- Envolver todos os eventos que efectuem um postback (OnClick, OnSelectedIndexChanged, OnRowClick, etc) num bloco Try/Catch e devolver uma Excepção com significado, para acelerar a resolução do erro em caso que necessite de manutenção.
- Todos os erros da aplicação deverão ser registados (Log) com os seguintes dados:
- Excepção
- Excepção Interna (InnerException) caso exista
- Stack Trace
- Data e Hora do Erro
- Se possível Nome do Utilizador e/ou Designação da Maquina (IP,Nome, etc)
Estas Informações são preciosas quando o erro ocorre num ambiente de Produção, e é necessário efectuar manutenção.
- Segurança nos URL
O principal meio de acesso ao site é o URL, logo este deverá ser robusto o suficiente para só dar acesso ao conteúdo devido, ou seja, um dos primeiros testes ao site devemos alterar o URL directamente, e verificar se por exemplo se consigo aceder a paginas que não deveria ter acesso, efectuar alterações a registos unicamente alterando o URL, etc.
- Uso abusivo do ViewState
O ViewState é o um campo oculto, com o ID = “__VIEWSTATE” na nossa pagina onde está registado o estado de cada controlo entre postbacks. Este registo está ligado para cada controlo que contenha o atributo runat=”server”. Se um formulário do nosso site conter muitos campos com muitos dados, o valor contido no campo de viewstate poderá ser enorme e a pagina terá uma performance muito baixa, porque o campo de viewstate é enviado e devolvido sempre em cada postback. Aqui ficam algumas dicas para minimizar o uso do viewstate:
- As Labels, por norma contem valores que não alteram o seu estado, logo na maioria dos casos pode ser desligado o viewstate destes controlos.
- Grelhas (GridView) que contenham dados só de visualização também poderá ser desligado o viewstate, visto que o seu conteúdo não altera de estado.
- Destruição Correcta de controlos
Os objectos que implementem o interface IDisposable deverão ser destruídos no final da sua utilização, afim de evitar consumo exagerado de memória por parte da aplicação. Os objectos que ficam por destruir com maior frequência são os de acesso aos dados (System.Data.Common.DbCommand,System.Data.Common.DbConnection, etc.) . A melhor forma de destruir um objecto é utilizar a instrução using.Exemplo:
SqlConnection conn;
try
{
conn = new SqlConnection();
conn.Open();
//(...)
}
finally
{
if (conn != null)
conn.Dispose();
} Poderá ser subtituido por isto: using (SqlConnection conn = new SqlConnection())
{
conn.Open();
//(...)
}Estas classes implementam o IDisposable e deveram ser usadas com a instrução using:System.Data.Common.DbCommandSystem.Data.Common.DbConnectionSystem.Data.Common.DbDataReaderSystem.Data.Common.DbTransactionSystem.Data.Linq.SqlClient.SqlProviderSystem.Data.OleDb.OleDbCommandSystem.Data.OleDb.OleDbConnectionSystem.Data.SqlClient.SqlDataReaderSystem.Drawing.BrushSystem.Drawing.FontSystem.Drawing.GraphicsSystem.Drawing.ImageSystem.IO.BinaryReaderSystem.IO.BinaryWriterSystem.IO.StreamSystem.IO.StreamReaderSystem.IO.StreamWriterSystem.IO.TextReaderSystem.IO.TextWriterSystem.Net.Mail.MailMessageSystem.Threading.TimerSystem.Web.UI.ControlSystem.Xml.XmlReaderSystem.Xml.XmlWriterEspero que estas dicas ajudem a melhorar a qualidade do vosso código, e optimize a performance dos vossos sites.