egomesbrandao, blog

Ia deixar para escrever sobre o assunto depois, mas pra começar bem a semana vou usar o comentário do Tucaz e fazer um Refactoring no código e tratar Execeptions, ou Exceções!

exceção
ex.ce.ção
sf (lat exceptione) 1 Ato ou efeito de excetuar. 2 Desvio de regra, de lei, de princípio ou de ordem. 3 A coisa excetuada; aquilo que se desvia da regra. 4 Prerrogativa, privilégio. 5 Pessoa cujo modo de pensar ou de proceder se afasta do comum e usual. 6 Dir Alegação jurídica, constituindo defesa indireta (difere da contestação, que é defesa direta), pela qual o réu pretende baldar a ação intentada. E. declinatória, Dir: a que visa a declinar a competência do juiz ou tribunal ao qual foi apresentada a demanda. E. dilatória, Dir: a que pretende apenas demorar a demanda. E. peremptória, Dir: a que de todo e definitivamente afasta a demanda.

Conforme a definição acima do Michaelis, exceção é um desvio da regra. Na classe Customer da camada de DAL, quando fazemos acesso ao banco de dados para buscar um ou mais usuários, a EntLib abre uma conexão e executa o comando Select, essa é a regra, mas e quando o banco de dados não esta disponível? Ou se alguém renomeou ou apagou a tabela que esta na nossa query? Isso são exceções, e se não tratarmos, o sistema para de funcionar! Para testar é só desligar o banco de dados (parando o serviço SQL Server Browser) e rodar o nosso software.

Existem várias correntes de pensamento sobre Exceptions

Devemos tratar Exceptions como conexões a banco de dados, mas se um usuário do sistema cadastrar um número inválido de CPF devemos lançar uma Exeception? Devemos criar nossas próprias Execeptions para o nosso sistema? Onde devemos tratar? Muitas perguntas, algumas vão ficar sem respostas no momento, o objetivo desse post será fazer o Refactoring, e o primeiro será na conexão do banco.

Tratamento de Exceptions

No .Net é usado a tríade Try-Catch-Finally, o código passível de erro e que pode vir a lançar uma exceção é colocado no bloco do Try, no Catch é onde se pegam as execeções, e o Finally serve para finalizar alguma operação, limpar alguma variável,  e, muitas vezes,  ele não é usado, mas no nosso primeiro exemplo já faremos uso dele.
Uma regra que devemos sempre atentar é: nunca, NUNCA, colocar um método inteiro dentro de um bloco Try, não há necessidade de colocar criação de variáveis! Teste somente o que pode dar um erro. Além disso,  o código fica mais elegante.

No código da classe Customer da camada de DAL o que pode dar erro? O mais óbvio seria quando o DataReader estivesse sendo carregado, se nessa hora o banco de dados cair o nosso software vai pro espaço! Como no método AdaptToList ainda usamos o DataReader (ele fica aberto para popularmos o objeto Customer)  vamos colocar a linha de ExecuteReader e a de chamada do AdaptToLista dentro do Try. Para fazer isso,  vamos usar o recurso de Refactoring da IDE :  selecione as duas linhas, clique CTRL, e no menu de contexto escolha Surrond With…

Fazendo um Surrond With no código

Escolha a opção “tryf”, conforme figura abaixo, repare que este é um atalho para um Snippet, então quando estiver escrevendo código usando este atalho economiza tempo!

Escolha "tryf"

O código estará dentro do bloco Try, veja outras alterações no código abaixo e em seguida o por quê

public Domain.Customer GetCustomerById(int customerId)
        {
            IDataReader dr = null;
            IList<Domain.Customer> lstCustomers = null;

            string sql = "select customerid, firstname, middlename, lastname, companyname, emailaddress, phone, modifieddate from saleslt.customer where customerid = @customerid";

            DbCommand cmd = db.GetSqlStringCommand(sql);

            db.AddInParameter(cmd, "customerid", DbType.Int32, customerId);

            try
            {
                dr = db.ExecuteReader(cmd);
                lstCustomers = AdaptToList(dr);
            }
            catch (System.Data.SqlClient.SqlException exsql)
            {
                throw new Exception(exsql.Message);
            }
            catch {
            }

            finally
            {
                if (!dr.IsClosed)
                    dr.Close();
            }

            return ((lstCustomers != null) || (lstCustomers[0] != null)) ? lstCustomers[0] : null;
        }
}

Listagem 01

Movi a declaração do DataReader para o início do método, pois podemos deixar dentro do Try, já que o Finally não iria enxergar esse objeto e depois é só mover a linha que faz a verificação se o DataReader estiver aberto para dentro do Finally, ocorrendo ou não um erro o Finally sempre é executado e daí ele ficará responsável por fechar o DataReader.
O Tucaz também fez um comentário sobre setar o CommandBehavior para CloseConnection, o que faria a conexão com o banco ser fechada após fecharmos o DataReader, mas a EntLib cuida disso pra gente! Veja o código fonte, e essa é a parte legal de usar essa biblioteca da MS, pois com o acesso ao fonte vemos as boas práticas sendo aplicadas, aquelas que se encontram no Guia de Acesso a Dados.
O Catch vazio vai pegar todo o tipo de exceção, então é bom especializarmos o Catch, por isso eu também coloquei para pegar a SQLException.

Aplique esse Refactoring no método GetCustomers() também.

OK… E vamos fazer isso também quando é criado o Database na classe BaseDAL, pois se o banco de dados estiver fora do ar vai dar um erro. É só executar os mesmos passos em cima da única linha que temos no único construtor da classe. E vai ficar assim:

    public abstract class BaseDAL
    {
        public EntLib.Database db { get; set; }

        public BaseDAL()
        {
            try
            {
                db = EntLib.DatabaseFactory.CreateDatabase("Connection String");
            }
            catch (Exception ex)
            {
                throw ex;
            }
            finally
            {

            }
        }
    }

Listagem 02
E agora temos que exibir esses erros lá na nossa interface de usuário, aqui vai o código de como vai ficar:

namespace ABCApp.Console
{
    class Program
    {
        static void Main(string[] args)
        {

            ABCApp.Domain.Customer c;

            ABCApp.DAL.Customer dalCustomer = new ABCApp.DAL.Customer();

            try
            {
                c = dalCustomer.GetCustomerById(1);
                System.Console.WriteLine(c.CustomerId.ToString() + " - " + c.FirstName.ToString() + " " + c.LastName.ToString());
            }
            catch (Exception ex)
            {
                System.Console.WriteLine(ex.Message);
            }

            System.Console.ReadKey();

            try
            {
                IList<Domain.Customer> lstCustomer = dalCustomer.GetCustomers();

                foreach (Domain.Customer customer in lstCustomer)
                {
                    System.Console.WriteLine(customer.CustomerId.ToString() + " - " + customer.FirstName.ToString() + " " + customer.LastName.ToString());
                }
            }
            catch (Exception ex)
            {
                System.Console.WriteLine(ex.Message);
            }
         �
            System.Console.ReadKey();
        }
    }
}

Vamos testar? Para isso desligue o seu SQL Server! Vá no menu Iniciar > Microsoft SQL Server 2008 > Configuration Tools > SQL Server Configuration Manager, entre na ferramenta.  Pare o serviço SQL Server Browser, daí não deve ser possível conectar na base. Rodando a aplicação devem ser impressas mensagens de erro onde deveriam aparecer dados!

Bom… Isso foi só para começarmos a colocar um controle sobre os locais onde podem ocorrer Exceptions, esse não é o mundo perfeito, e nem será a última vez que irei falar sobre o tema. Mas por que não ler alguns links sobre isso? Aí vai:

http://unplugged.giggio.net/unplugged/post/Como-tratar-erros.aspx

http://msdn.microsoft.com/en-us/library/dd203116.aspx (Esse é sobre o bloco de Exceptions da EntLib, mais pra frente vamos usar ele)

http://www.developerfusion.com/article/5250/exceptions-and-performance-in-net/ (discute a questão de performance ao lançar exceções)

http://yoda.arachsys.com/csharp/exceptions2.html (também sobre performance)

http://www.artima.com/interfacedesign/AbnormalConditions.html

http://apparch.codeplex.com/ (aqui tem um vídeo sobre o tema)

Fico por aqui… Na quinta-feira post sobre objetos anêmicos…

O código deste post esta no Change Set 36605.

No post anterior,  iniciamos a contrução da ABC App, construindo uma camada de Domínio e uma camada de DAL. Antes de continuarmos a desenvolver, vamos aplicar um Refactoring?

Eu não gosto de termos em inglês para coisas que podemos falar em português, mas no caso do Refactoring eu abro uma exceção, normalmente o que se fala é Refatoração, mas essa palavra para mim é um termo matemático. O correto, IMHO, seria dizer Re-fabricar, mas fico com o termo em inglês.

E o que podemos fazer?

Vamos seguir usando Baby Steps, daqui por diante pequenos passos, ou seja , faço Refactoring e testo, Refactoring e testo, então não corro o risco de fazer uma grande alteração e me perder no código alterado e o sistema não funcionar. A primeira coisa para alterar é a criação da conexão com o BD, como será recorrente em toda classe DAL, podemos criar um classe base que todas dessa camada herdem e,  assim,  centralizarmos o código. Então,  primeira coisa, crie uma classe BaseDAL, como abaixo:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using System.Data;
using System.Data.Common;
using System.Resources;
using EntLib = Microsoft.Practices.EnterpriseLibrary.Data;

namespace ABCApp.DAL
{

    public abstract class BaseDAL
    {
        public EntLib.Database db { get; set; }

        public BaseDAL()
        {
            db = EntLib.DatabaseFactory.CreateDatabase("Connection String");
        }
    }
}

Listagem 01

A classe BaseDAL não poderá ser instanciada, só poderá ser herdada. Com isso, ganhamos um único ponto de conexão com o Banco de Dados, que será muito útil quando quisermos controlar um transação, outro ponto é no reuso de código. Para usarmos essa classe vamos herdar ela na classe Customer da DAL. Não se esqueça de apagar a linha indicada, pois agora usaremos o objeto Database da classe BaseDAL. Lembram-se do código abaixo?

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using Domain = ABCApp.Domain;

using System.Data;
using System.Data.Common;
using System.Resources;
using Microsoft.Practices.EnterpriseLibrary.Data;

namespace ABCApp.DAL
{
    public class Customer : BaseDAL
    {
        public Domain.Customer GetCustomerById(int customerId)
        {
            //Apague a linha abaixo
            //Database db = DatabaseFactory.CreateDatabase("Connection String");

            string sql = "select customerid, firstname, middlename, lastname, companyname, emailaddress, phone, modifieddate from saleslt.customer where customerid = @customerid";

            DbCommand cmd = db.GetSqlStringCommand(sql);

            db.AddInParameter(cmd, "customerid", DbType.Int32, customerId);

            IDataReader dr = db.ExecuteReader(cmd);

            Domain.Customer c = new Domain.Customer();

            while (dr.Read())
            {
                c.CompanyName = dr["companyname"].ToString();
                c.CustomerId = Convert.ToInt32(dr["customerid"]);
                c.EmailAddress = dr["emailaddress"].ToString();
                c.FirstName = dr["firstname"].ToString();
                c.LastName = dr["lastname"].ToString();
                c.MiddleName = dr["middlename"].ToString();
                c.ModifiedDate = Convert.ToDateTime(dr["modifieddate"]);
                c.Phone = dr["phone"].ToString();
            }

            if (!dr.IsClosed)
                dr.Close();

            return c;
        }
    }
}

Listagem 02

Se já tivéssemos escrito mais classes DAL, o impacto dessa alteração seria muito maior. Então , seguindo nossso mantra de pequenos passos, vamos executar o código e saber se ele continua funcionando como o esperado.
Sendo o retorno igual ao que você tinha antes de modificar o código, então passamos neste Refactoring!
Vamos continuar implementando outros métodos na nossa classe DAL, o próximo interessante é retornar uma coleção de clientes. Podemos retornar todos os clientes e basicamente o método seria o mesmo do anterior mas sem o parâmetro de customerId e sem a linha de parâmetro no Command, vou criar então o método GetCustomers e que irá me retornar uma lista tipada de objetos, segue:

public IList<Domain.Customer> GetCustomers()
        {
            List<Domain.Customer> lstCustomers ;

            string sql = "select customerid, firstname, middlename, lastname, companyname, emailaddress, phone, modifieddate from saleslt.customer";

            DbCommand cmd = db.GetSqlStringCommand(sql);

            IDataReader dr = db.ExecuteReader(cmd);

            lstCustomers = new List<Domain.Customer>();

            while (dr.Read())
            {
                Domain.Customer c = new Domain.Customer();

                c.CompanyName = dr["companyname"].ToString();
                c.CustomerId = Convert.ToInt32(dr["customerid"]);
                c.EmailAddress = dr["emailaddress"].ToString();
                c.FirstName = dr["firstname"].ToString();
                c.LastName = dr["lastname"].ToString();
                c.MiddleName = dr["middlename"].ToString();
                c.ModifiedDate = Convert.ToDateTime(dr["modifieddate"]);
                c.Phone = dr["phone"].ToString();

                lstCustomers.Add(c);
            }

            if (!dr.IsClosed)
                dr.Close();

            return lstCustomers;
        }

Listagem 03

E para testar o código acima vamos escrever as seguintes linhas no nosso método Main no Projeto Console, logo abaixo da última linha já existente do nosso teste anterior:

            IList<Domain.Customer> lstCustomer = dalCustomer.GetCustomers();

            foreach (Domain.Customer customer in lstCustomer)
            {
                System.Console.WriteLine(customer.CustomerId.ToString() + " - " + customer.FirstName.ToString() + " " + customer.LastName.ToString());
            }

            System.Console.ReadKey();

Listagem 04

O código acima chama o método da DAL e retorna uma coleção de Clientes. Se aparecerem  várias centenas de Clientes,  está certo!
O código escrito até agora. Será que é possível aplicar um Refactoring para melhorar algo? Bom, tem algo bem evidente, uma duplicação de código, os dois métodos fazem a leitura do DataReader e populam um objeto Customer, e um deles ele adiciona a uma lista de objetos já que o retorno são vários. Podemos centralizar esse código para que quando for preciso adicionar uma nova Propriedade a classe Customer seja preciso alterar somente em um lugar, então vou criar o método AdaptToList que irá receber um DataReader e retornar uma lista tipada de Customer:

public IList<Domain.Customer> AdaptToList(IDataReader dr)
        {

        }

Listagem 05

O código da listagem 05 está praticamente pronto. Mova o código que se encontra na listagem 03, da linha 11 até 27 para dentro do método AdaptToList, e adicione a última linha, conforme a listagem 06! E repare que na inicialização da coleção Customer a declaração estava em outra linha,  então acrescente o tipo antes.

        public IList<Domain.Customer> AdaptToList(IDataReader dr)
        {
            List<Domain.Customer> lstCustomers = new List<Domain.Customer>();

            while (dr.Read())
            {
                Domain.Customer c = new Domain.Customer();

                c.CompanyName = dr["companyname"].ToString();
                c.CustomerId = Convert.ToInt32(dr["customerid"]);
                c.EmailAddress = dr["emailaddress"].ToString();
                c.FirstName = dr["firstname"].ToString();
                c.LastName = dr["lastname"].ToString();
                c.MiddleName = dr["middlename"].ToString();
                c.ModifiedDate = Convert.ToDateTime(dr["modifieddate"]);
                c.Phone = dr["phone"].ToString();

                lstCustomers.Add(c);
            }

            return lstCustomers;
        }

Listagem 06

Para funcionar só é preciso chamar o método AdaptToList no método GetCustomers,  também alterei para que a lstCustomer fosse baseada em uma IList<T>, conforme a listagem abaixo:

        public IList<Domain.Customer> GetCustomers()
        {
            IList<Domain.Customer> lstCustomers = null; 

            string sql = "select customerid, firstname, middlename, lastname, companyname, emailaddress, phone, modifieddate from saleslt.customer";

            DbCommand cmd = db.GetSqlStringCommand(sql);

            IDataReader dr = db.ExecuteReader(cmd);

            lstCustomers = AdaptToList(dr);

            if (!dr.IsClosed)
                dr.Close();

            return lstCustomers;
        }

Listagem 07

Mais um pequeno passo, e mais um teste! Se rodou e continuou funcionando é por que o seu Refactoring foi bem feito! O que falta? Bem, se AdaptToList foi contruído para economizar código devemos usá-lo também no método GetCustomerById, mas nesse último método ele retorna apenas um Customer e não uma lista. Podemos então usar um artifício: pegar somente o primeiro item da lista para retornar, conforme listagem abaixo: 

public Domain.Customer GetCustomerById(int customerId)
        {
            IList<Domain.Customer> lstCustomers = null;

            string sql = "select customerid, firstname, middlename, lastname, companyname, emailaddress, phone, modifieddate from saleslt.customer where customerid = @customerid";

            DbCommand cmd = db.GetSqlStringCommand(sql);

            db.AddInParameter(cmd, "customerid", DbType.Int32, customerId);

            IDataReader dr = db.ExecuteReader(cmd);

            lstCustomers = AdaptToList(dr);

            if (!dr.IsClosed)
                dr.Close();

          �
            return ((lstCustomers != null) || (lstCustomers[0] != null)) ? lstCustomers[0] : null;
        }

Listagem 08

Na listagem 08 está o método GetCustomerById como deve ficar, a mudança do List<Domain.Customer> para IList<Domain.Customer>, a chamada do método AdaptToList e o pulo do gato que é o uso do operador ternário para retornar somente o primeiro item da coleção, ou seja um objeto Customer, ou um null, não vamos discutir agora se retornar nulo é uma boa opção ou não!

Vou finalizar o post por aqui, para não ficar muito grande, resumindo o que fizemos aqui: Refactoring!
Melhoramos o nosso código, parece que não é necessário fazer isso agora, mas sempre que possível é interessante a fazer, no caso criamos uma classe para cuidar inicialmente da conexão com o banco de dados e como criamos outro método que populava a classe Customer criamos um método para cuidar especificamente disso.

O código deste post encontra-se no Change Set 35524, dúvidas e sugestões por favor comentem!

Referências:

Wikipedia Refatoração

Wikipedia Refactoring

Wikipedia Code Refactoring