Reflection No Dia a Dia – Parte 01

Geralmente quando falamos de Reflection pensamos em códigos sendo gerados em runtime, carregar uma dll dinamicamente e coisas que assustam, mas por outro lado podemos usar reflection para coisas bem menos complexas, porém muito uteis.

Por exemplo no código abaixo uso reflection para pegar o nome do método onde a exception foi gerada.

Utilizo o getype().tostring para pegar o nome do objeto e com  MethodBase.GetCurrentMethod().Name pego o nome do método , assim logo o nome da classe e do método onde o erro ocorreu, poderia estar logando o tempo de execução do método.
…..
catch (Exception ex) {
               
                retorno = false;

                System.Diagnostics.Trace.WriteLine(this.GetType().ToString() + " – " + System.Reflection.MethodBase.GetCurrentMethod().Name + "[" + ex.Message + "]");
           
            }

Para uma visão geral dos recursos da utilização de Reflection sugiro os links : http://www.linhadecodigo.com.br/ArtigoImpressao.aspx?id=264
e http://iamacamera.org/default.aspx?section=home&id=58

Comparação de Texto (String)

Embora seja uma das tarefas mais triviais da programação a comparação entre strings costuma gerar muito bugs nos sistema por um simples detalhe.
No .Net assim como na maioria das linguagens de programação por padrão a comparação de string é case sensitive, com isso temos erros como

var1 = "teste";
var2 = "Teste";

if (var1 == var2)
//aos olhos do programador inexperiente o código deveria executar essa parte
else
// mas como a comparacao é case sensitive o bloco executado será esse

/////////////////////// Para corrigir esse pequeno Bug devemos usar o código abaixo //////////////////////////////////
if (var1.Equals(var2, StringComparison.OrdinalIgnoreCase))
  // Agora sim esse código sera executado
else
 //E esse sera ignorado

Outra forma  de evitar esse erro seria usar a função ToLower (caixa baixa) ou  ToUpper (caixa baixa) para que ambos as variaveis fiquem com a mesma caixa.

Links de referência:
http://msdn.microsoft.com/en-us/library/system.stringcomparison.aspx

http://msdn.microsoft.com/en-us/library/ms973919.aspx

Padrão para Métodos – Part 1

Muito ja li sobre padrões de como os métodos devem ser feitos , ja vi muito código de outros programadores e também os meus códigos antigos, com base nessa experiência vou listar os pontos positivos e negativos que ja vi nesses quase 10 anos de profissão:
 
Métodos com mais de 100 linhas, porque:

Nunca Faça
    • Nem você vai entender o código direito depois de duas semanas
    • Dificil entendimento , terrível para dar manutenção
    • Mais dificil de evoluir
    • Está fazendo mais do que o nome do método Diz …

Tente Fazer

    • Métodos que possam ser lidos na resolução de 1024  sem precisar de scroll
    • Crie métodos auxiliares para decompor o código, assim fica facil de melhorar e debugar problemas
    • O código do método deve fazer o que o nome sugere assim o código fica de facil entendimento , ficando quase auto documentado

Métodos com 30 parametros
Nunca Faça

  • Fica complicado  de ver todos os parametros. Provavelmente você esteja fugindo da orientação a objeto
  • Fica facil inverter a ordem de algum valor e daí haja debug para achar o erro

Tente Fazer

  • Procure criar objetos e passar os objetos para o método ou trabalhar com propriedades

 

Duplicação de código Ctrl + C , Ctr + V

Nunca Faça

  • Código duplicado significa dois lugares para corrigir e/ou melhorar
  • Torna o código mais extenso do que o necessário
  • Aumenta em muito as chances de bug na aplicação, pois qualquer alteração tem que mapear os lugares onde o código esta duplicado

Tente Fazer

  • Quando precisar de uma funcionalidade que esta embutida em algum método, extraia a mesma para um método separado
  • Métodos com poucas linhas tendem a ser reutilizados, pois são bem especializados numa tarefa

 

Regra de Negócio  utilizando exception

Nunca Faça

  • Utilizar exception para regra de negócio degrada a performance
  • Falta de planjemanento

Tente Fazer

  • Trabalhe com o envio de mensagens
  • Planeje a troca de mensagens, para facilitar tanto a camada de negócios como a interface da aplicação

 

 

 

.Net Usando TryParse

Na versão 1.1 do .Net  não tinhamos uma maneira de checar se um valor era numerico do tipo Int , usando as classes de compatilibilidade do vb tinhamos a famosa função isnumeric , mas um isnumeric = true não significava isInt =true . A versão 2.0 do .Net trouxe o método Tryparse que recebe como parametro um valor e uma variavel  , se o valor for compativel ele retorna true e seta o valor da variavel , senão ele retorna false.
 
O código abaixo irá retornar  true para a variavel valor3 e 200 para variavel valor2:
 

Dim valor As String = "200"

Dim valor2 As Integer

Dim valor3 As Boolean

valor3 =

Integer.TryParse(valor, valor2)

Podemos utilizar esse método para validar data , assim como validar um endereço de IP. O código abaixo ira validar se  o valor é um ip válido.

 

Dim

ip1 As String = "200.200.1.2"

Dim valor4 As Boolean

Dim ip As System.Net.IPAddress

valor4 = System.Net.IPAddress.TryParse(ip1, ip)

 

Então agora na versão 2.0 não tem mais desculpa para utilizarmos a geração de exception para esses casos, o que deve ser sempre ser evitado…. pois como o nome mesmo diz exception  deve ser uma excessão …  … e não um fluxo nomal do seu código.

 

 
 
 

ASP.NET – Documentos do Office com OPENXML

Algum tempo já estou estudando sobre o assunto , tendo criando um sistema de geração de cartas que pretendo escrever um post especifico sobre isso…
 
Mas hoje só vou deixar alguns links que me ajudaram nessa caminhada …
 
O Openxml Developer foi a principal fonte de informações que encontrei e me ajudou muito me poupando um bom tempo e também com ótimos fontes.
 
Pessoal da Unicamp fez algumas coisas bem interessantes, pena que não evoluiu tanto depois de um começo promissor….
 
Esses descobri esse mês…
 
 

ASP.NET – Confirmação de Exclusão

É muito comum termos que exibir uma mensagem de confirmação quando o usuário tenta excluir um item , seja ele um pedido, produto, usuario, etc.
 
Em 99% das vezes temos que pedir a confirmação para evitar transtornos, como o usuário excluir algo que não deve porque clicou sem querer.
 
 
Como nos meus projetos coloco isso como padrão estava pensando em como fazer isso de algo automatico, para que eu ou outro desenvolvedor desatento ou num momento de saco cheio , não esqueça de coloca-lo.
 
Então nos meus pensamentos lembrei de um post  do Fernando Cerqueira sobre como corrigir um problema ao utilizar webparts com ajax http://thespoke.net/blogs/fcerqueira/default.aspx , esse grande conceito chama-se  tagMapping com esse cara você pode dizer pro .net , ao invés de utilizar
a classe System.Web.UI.WebControls.ImageButton para um image button usa a minha.
 
Então eu criei uma classe herdando de ImageButton e customizei o evento init para configurar o bendito confirm sempre que o ImageButton tiver a propriedade CommandName igual a DELETE
 
Assim todos os meus grids que possuem o controle ImageButton delete , possuem a confirmação automaticamente, a unica coisa que faço no gridview é converter a coluna com os botões de ações para template e mudo de linkbutton para imagebutton, essa parte eu ja fazia, pois tenho um skin com a imagem de cada botão. Veja abaixo como fica o webconfig.
<pages>
<tagMapping>
<
add tagType="System.Web.UI.WebControls.ImageButtonmappedTagType="AKAMAE_CONTROL.ImageButtonAkamae"  />
</
tagMapping>
</
pages>
 
 Esse recurso poderia ser utilizado para trocar todos os textbox para um componente de terceiro sem precisar entrar em cada página para fazer isso … Abaixo a gloriosa classe …
 

Public

Class ImageButtonAkamae

Inherits ImageButton

 

Private Sub ImageButtonAkamae_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init

If (Me.CommandName IsNot Nothing) AndAlso (Me.CommandName.ToUpper() = "DELETE") Then

Me.OnClientClick = "return (confirm(‘Confirma exclusão?’));"

End If

End Sub

End

Class