A minha história com o VB começou no início dos anos 2000, quando eu ainda trabalhava com projetos de automação predial. Cheguei a programar uma ou outra vez nessa época nas controladoras que utilizávamos porém em uma linguagem totalmente visual, que era um arrastar e soltar de blocos que representavam ventiladores, sensores, motores… Mas a maior parte do meu trabalho foi desenhando esquemas elétricos no AutoCAD, que para quem não conhece,  é o software padrão para desenhos de engenharia 2D e 3D. Com o meu amadurecimento no uso da ferramenta, comecei a sentir a necessidade de automatizar algumas coisas no meu trabalho. Acho que quando se conhece um processo tão profundamente as tarefas ficam tão monótonas que se começa a pensar em como podemos tornar essa tarefa melhor, mais rápida e melhor  ou ainda mais assertiva; e aí estava uma oportunidade escrever código dentro da ferramenta para atingir esses objetivos! Eu sempre gostei da ideia de programar, havia feito um curso de C, mas foi com ênfase em eletrônica, que era minha área na época. O AutoCAD até a versão 14 oferecia LISP, C++, e talvez outras coisas, para programar. Eu tentei estudar LISP (Lost In Stupid Parantheses), mas foi chato pra caramba. Até que na versão 2000, a Autodesk, incluiu o VBA para AutoCAD! Sim, o mesmo VBA que já estava presente no Access, Excel, Word. O VBA me permitiu não só criar macros para blocos de desenho no AutoCAD, como também acessar uma base de dados, criar Forms para entrada de dados, tudo de uma maneira muito simples, até mesmo para alguém sem conhecimentos profundos na área. Eu comecei aí, mas não parei, tive um mentor a época, Felipe Antunes (escreve o blog “E agora DBA”), que me ajudou muito em questões básicas, em entender como funcionava um banco de dados relacional, o que me fez pular do Access para o SQL Server em pouco tempo. Fiz os treinamentos oficiais do VB6, até mesmo o 1016 que envolvia coisas como MTS (na época do Windows NT) e COM+. Adotei a famosa arquitetura WinDNA. E consegui desenvolver um software que solucionava um gap entre a área comercial e a de projetos, agilizando o processo, dando confiabilidade a informação, e por aí vai. Não é preciso dizer o quanto fiquei entusiasmado com isso, já que vim para a área de TI logo em seguida.

Mas não é por conta da minha história com a linguagem que ela tem prestígio para mim e sim por causa da história da própria linguagem. Antes,  o que quer dizer prestígio? Segundo a Wikipedia: “…se referia à ilusão causada aos espectadores pelos truques de um mágico”. “(…) O termo foi usado com este sentido até século XVIII, quando em francês se começou a dar a ‘prestige’ o significado de renome, ascendência, influência, e o prestígio francês nas cortes da Europa traduziu este significado para a nossa lingua”. O uso atual “(…) descreve importância social, alta consideração e sólida reputação”.

No fim da década de 90 e início dos anos 2000 a linguagem que tinha mais influência no mercado, corporações, produtos, … era o Visual Basic, que chegou até a versão 6, trouxe um grande poder ao desenvolvedor, no sentido de tornar simples o desenvolvimento, fazer um acesso a base de dados relacional, criar uma tela gráfica, acessar a API do Windows, desenvolver uma aplicação distribuída, tinha ficado muito mais simples. Em 2005 62% dos programadores usavam uma forma de Visual Basic (Wikipedia), já que nessa época já estavamos entrando na versão 2.0 do VB.Net, mas até hoje o Visual Basic 6 é utilizado em produção, em projetos, até mesmo alguns novos projetos são desenvolvidos com ele! Talvez atualmente o Visual Basic 6 não seja a melhor opção para desenvolver um projeto, mas no início dos anos 2000 era uma das melhores opções, Java ainda era extremamente lento e complexo, de se programar, de se criar um ambiente, o Delphi apesar de prático exigia um pouco mais. O VB dava poder para quem estava começando, dava agilidade. Mas com todo esse poder também vinha uma grande responsabilidade, que era ignorada.  Com a mesma simplicidade que se desenvolvia no VB,  se criava uma grande dívida técnica! Infelizmente o descontrole dos projetos, de arquitetura, de boas práticas não é culpa da linguagem. Não podemos culpar armas, carros, aviões por matar pessoas! Os próprios desenvolvedores foram os culpados por toda essa quantidade de brownfield que se criou na plataforma. E que não venham dizer que foram forçados a isso, que a gerência mandou. Ninguém faz o que não quer!

Por fim, o VB.Net resolve o problema do cliente, que é o objetivo com que qualquer linguagem é criada, fora linguagens teóricas. E isso que é importante, juntamente com o cuidado de se escrever um código limpo.

Histórinha do ForEach: Depois dos Generics, disponibilizado no framework 2.0, se tornou comum o uso de listas tipadas, muito melhores que o uso de Arrays de Objects! Também foi introduzido os tipos anônimos, expressões Lambda. Em seguida na versão 3.5 do framework foi introduzido o Linq, mudando a forma como são manipuladas coleções de objetos.

Se é necessário somar o valor dos itens de uma nota fiscal o modo “old school” é:

List<Item> itens = new List<Item>();

itens.Add(new Item() { Valor = 10.3M });
itens.Add(new Item() { Valor = 11.7M });
itens.Add(new Item() { Valor = 15.8M });

decimal valorTotal = 0;

foreach (Item item in itens)
{
 valorTotal += item.Valor;
}

Ou você pode fazer:

List<Item> itens = new List<Item>();

itens.Add(new Item() { Valor = 10.3M });
itens.Add(new Item() { Valor = 11.7M });
itens.Add(new Item() { Valor = 15.8M });

decimal valorTotal = 0;

itens.ForEach(item => valorTotal += item.Valor);

Mas fora a diferença de sintaxe, existe alguma outra? Performance? E o que é esse método ForEach?

ForEach é um método que recebe como parâmetro um delegate Action<T>, ou seja ele recebe uma função a ser executada, nesse caso será executado um foreach!! Sem emoção aqui, mas o legal é que percorrer uma coleção fazendo alguma alteração em seus itens agora requer apenas uma linha.

Mas não é só isso! Voltando a nossa questão de performance o ForEach é mais otimizado sim, eu ia fazer um pequeno projeto de teste mas… achei um post falando justamente sobre isso, então para reaproveitar código quem quiser testar é só usar o projeto que foi disponibilizado pelo Dustin Russell Campbell aqui neste post. A comparação é bem completa, usando vários tipos de interação (For, foreach, ForEach), e o ForEach ganha! Somente quando o código esta usando otimização na compilação com uma coleção pequena a velocidade se equipara, mas a medida que a quantidade de itens aumenta ele é mais rápido que outros métodos.

A quem não goste

Encontrei também comentários de pessoas que não gostam dessa abordagem, dizendo que ela não adiciona poder representativo a linguagem, o exemplo dado no link é bem simples então o autor tem razão. Porém minha opinião é que o código fica muito mais legível, tornando a leitura mais fluída.

Objetivo: Popular um objeto simples com dados do banco sem fazer uso de Dataset

O que é necessário: Visual C# Express, MS SQL Express 2K8, banco de exemplo Adventure Works 2K8, MS Enterprise Library 4.1

Preparando o ambiente: Para quem nunca instalou o banco de exemplo Adventure Works, ele se encontra no CodePlex neste link aqui, mas tem uma pegadinha! Se não instalou o SQL Express Advanced, é um download maior, você não tem SQL Full Text Filter (veja se tem no Configuration Manager do SQL, é um serviço) e daí a instalação automática das bases de dados vai falhar, você terá que rodar os scripts manualmente, mas vai ter que alterar algumas variáveis. Então é melhor você ter a versão SQL Full Text Search, que está aqui. Usaremos somente o LT, que é mais enxuto em quantidade de tabelas, mas totalmente compatível com sua versão completa.
Quanto à MS Enterprise Library 4.1, ela é encontrada aqui, quando terminar o instalador vai perguntar se deseja compilar, responda Sim.

Pronto?

Se imaginarmos que estamos em um ambiente real de negócio nos já temos o BD, que é o Adventure Works, o que precisamos fazer é contruir uma classe de Customer (Cliente) que vai ser populada com os dados da tabela Customer do BD, dentro de um projeto Class Library que eu chamei de ABCApp.Domain:

namespace ABCApp.Domain
{
    public class Customer
    {
        public int CustomerId { get; set; }
        public string FirstName { get; set; }
        public string MiddleName { get; set; }
        public string LastName { get; set; }
        public string CompanyName { get; set; }
        public string EmailAddress { get; set; }
        public string Phone { get; set; }
        public DateTime ModifiedDate { get; set; }
    }
}

Como o nosso objetivo aqui é não usar Dataset e também agora não iremos usar ORM (não sabe o que é? espere próximos posts), vamos usar ADO.Net, mas para facilitar as coisas vamos usar a MS Enterprise Library (que chamarei daqui em diante de EntLib). Vamos criar então um novo projeto que será a nossa DAL, Data Access Layer, camada de acesso a dados:

using ABCApp.Domain;

using Microsoft.Practices.EnterpriseLibrary.Data;

namespace ABCApp.DAL
{
    public class Customer
    {
        public Customer GetCustomerById(int customerId){

        }
    }
}

Repare que eu já adicionei duas referências, uma à EntLib, na janela Add Reference procure por Enterprise Library Data Access Application Block; e adicionei uma referência ao meu projeto ABCApp.Domain.
A primeira é para poder usar o bloco de acesso a dados da EntLib, e isso só vai ocorrer nesse projeto de DAL, que é minha camada de acesso a dados, a camada de Domain não vai saber onde os dados estão sendo persistidos!
E a segunda referência é porque o objeto que eu quero popular está na camada de domínio da aplicação.

Antes de continuarmos escrevendo a DAL, precisamos configurar como a EntLib irá fazer a conexão com o BD, e antes de fazermos isso precisamos adicionar um novo projeto a Solution, vamos adicionar um projeto do tipo Console para testarmos o código, por hora, por que existem maneiras melhores de fazer isso, mas não será feito nesse post. A Solution deverá ficar assim:

A Solution deverá estar parecida com essa figura

Insira um arquivo do tipo App.config no novo projeto, é nele que iremos configurar a conexão com o BD, e para isso existe uma ferramente que é integrada ao VS.Net no momento da instalação da EntLib, mas como estou fazendo na versão Express vamos usar a ferramenta externa que também é instalada, procure no menu Inicar: Microsoft Patterns & Practices > Enterprise Library 4.1 – October 2008 > Enterprise Library Configuration, e você terá a seguinte tela:

Quando abrir a janela, vá em File > Open, e procure pelo arquivo App.config criado no projeto Console. Na pasta Connection String você pode criar várias conexões, mas no momento só precisamos de uma, apague as outras e crie uma nova, do lado direito da tela em General > ConnectionString preencha com as informações de localização do SQL Express, BD, senha, … o padrão. Salve o arquivo, feche, e ao voltar ao VS.Net Express ele vai pedir para recarregar o arquivo App.config, se ele ficou aberto.

Agora finalmente vamos codificar o acesso ao BD, segue abaixo.

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
    {
        public Domain.Customer GetCustomerById(int customerId)
        { �
            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;
        }
    }
}

Explicando o código acima

Primeiramente repare nos Using, eu acrescentei uma referência ao projeto ABCApp.Domain, pois é lá que esta a classe que eu quero popular; e ao System.Data e System.Data.Common, pois vou usar o objeto Command e o DataReader do ADO.Net.
Na linha 14 eu estou criando o “BD”, essa DatabaseFactory vai criar automáticamente uma Connection para mim, através da minha ConnectionString configurada, e através desse objeto vamos interagir com o BD. A vantagem é que a EntLib vai cuidar da conexão para a gente, abrir, fechar, e outras coisas!
O objeto Command já é conhecido de quem já programou com ADO.Net, o legal aqui é que na linha 20 é criado um objeto de parâmetro, normalmente se concatenaria o código na string mas não é uma prática muito recomendada.
A grande diferença aqui é o uso do Data Reader, como não estamos usando um DataSet, vamos puxar os dados do BD e popular um objeto, que é feito na linha 22, então é só ler o objeto dr e ir populando os dados depois de inicializado o nosso objeto de Domain.

Para testar é só escrever o código abaixo no Main do nosso projeto Console.

static void Main(string[] args)
        {

            ABCApp.Domain.Customer c;

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

            c = dalCustomer.GetCustomerById(1);
     �
            System.Console.WriteLine(c.CustomerId.ToString() + " - " + c.FirstName.ToString() + " " + c.LastName.ToString());

            System.Console.ReadKey();
        }

Qual a vantagem de usarmos isso tudo?

Bom, primeiramente estamos programando realmente em OO, temos um objeto de domínio, a camada de acesso a dados esta isolada do resto, e principalmente não estamos usando DataSet!

Se você quiser baixar o código esta disponível no CodePlex – ABCApp e baixe o Change Set – 33351.

No próximo post (assine o feed para acompanhar) vou mostrar o que podemos fazer de interessante tendo esse objeto de domínio e vou fazer um Refactoring para darmos uma melhorada no código já, pois a idéia aqui era mostrar mais o acesso através da EntLib e como fazer sem o uso de DataSet. Até lá!
Críticas, sugestões, dúvidas são sempre bem-vindas, use o recurso de comentário do blog, a sua dúvida pode ser a de outro, e fica disponível para todos!

falácia¹
fa.lá.cia¹
sf (lat fallacia) 1 Qualidade de falaz. 2 Engano, logro, burla. 3 Sofisma.

sofisma
so.fis.ma
sm (gr sóphisma) 1 Lóg Raciocínio capcioso, feito com intenção de enganar. 2 Argumento ou raciocínio falso, com alguma aparência de verdade. 3 pop Dolo, engano, logro.

Antes de começarmos a codificar alguma coisa, é bom um pouco de história para nos situarmos ! O termo foi difundindo erradamente. Vamos começar do começo e por partes, ou camadas , se preferir.

Tive um primeiro contato com o termo desenvolvimento em camadas por volta do ano 2000. Na época, uma das linguagens mais usadas era o Visual Basic 6.0, o Java estava crescendo, e o Delphi era bem usado. A Microsoft recomendava o uso de ADO, presente no pacote MDAC, em detrimento ao DAO. O objetivo era ir no banco o mais tarde possível, pegar os dados e fechar a conexão o mais cedo possível. Surgiu então o Win DNA (Windows Distributed interNet Applications Architecture), como o link diz é um nome marketeiro para tecnologias que já existiam mas foram agrupadas em uma arquitetura (COM, COM+, antigo MTS; ADO, ActiveX, ASP). Na época a minha bíblia era o livro Mary Kirtland, posteriormente li também o livro do Fábio Câmara.

A arquitetura Win DNA

A MS,  então,  comecou a divulgar a divisão de responsabilidades. A maioria dos programadores VB na época não usava nem o conceito de Classe, isso passou a ser mais demonstrado nos exemplos e no próprio livro, mas como o VB não era verdadeiramente OO não surtiu muito efeito. Até mesmo a divisão em DLL’s não era comum, o que mais se via eram executáveis gigantescos ou vários gigantescos por módulo!

O acesso aos dados era feito usando-se o RecordSet do ADO, criava-se um, ia no banco de dados, populava ele, fechava-se a conexão e usava na aplicação. A arquitetura,  então, era os Formulários (Form) no EXE e DLL’s;  A escrita do CRUD ficava em uma DLL. Na época,  a MS incentivava o uso massivo de Stored Procedures. E começou um movimento para tirar a lógica de negócios da camada de apresentação, ainda na fase dessa arquitetura era muito comum ter regras no banco de dados, mas falava-se em colocar essas regras em DLL’s também, então a camada de apresentação chamava uma DLL que continha algumas regras, que chamava a DLL de CRUD, que populava um RecordSet e retornava pela cadeia até a tela do usuário.

As coisas mudam no .Net

Com a vinda do .Net tivemos uma migração de algumas aplicações de maneira automática por meio de Wizards, alguns programadores também começaram a programar em VB.Net ou foram para o C#, uma linguagem mais de “gente grande” por ser mais parecida com Java. Porém,  o paradigma é diferente! VB 6.0 não é puramente OO, VB.Net sim! Aliás, o VB.Net é somente a sintaxe do VB 6.0, ele é uma linguagem em cima de outra plataforma.

Mas as pessoas são acostumadas a hábitos e,  o desenvolvimento em .Net foi feito da mesma maneira que vinha sendo feito no VB 6.0: lógica separada dos dados.

O paradigma OO nos diz: Cada classe determina o comportamento (definido nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. (fonte: Wikipedia)

Na arquitetura Win DNA os dados ficavam em um RecordSet e o comportamento em funções de uma classe em uma DLL, o RecordSet passeava pela aplicação e,  se ela fosse um controle de Estoque uma função recebia o RecordSet, percorria ele para ver se algum item estava zerado para gerar um novo pedido.

Na arquitetura OO não existe essa separação, o que eu quero mostrar com os próximos posts é que ao termos objetos de domínio, estamos facilitando o desenvolvimento por deixarmos tudo agrupado (comportamento + estado), a facilidade de manutenção será muito maior. Outra coisa, o uso de DataSet’s deixa o código também mais confuso, usando classes POCO o código será muito mais fácil de entender e leve.

Continue acompanhando!

Resolvi que não vou focar em MVC, vou usar o projeto para escrever sobre boas práticas, coisas que uso no meu dia- a-dia, então mudei o nome dele novamente (hehe) e ficou assim: ABC App.

Aqui no blog vou usar a categoria abcapp para publicar os posts referentes a essa série.

O código fonte deste projeto está hospedado no CodePlex em ABCApp, e , como o projeto é para quem também está iniciando então vou usar as ferramentas Express da Microsoft, Visual C# Express 2008. Vou usar também o TortoiseSVN, é só baixar o arquivo MSI e instalar. Antes , para acessar o CodePlex usando o TortoiseSVN era necessário o uso do  SvnBridge, desenvolvido pela equipe do site, agora não é mais necessário. Todo o projeto tem uma URL para ele, do ABCApp é https://abcapp.svn.codeplex.com/svn.

Eu criei o projeto na pasta Projects que o VS.Net cria dentro da pasta Documentos do Usuário.

Depois que você instalou o TortoiseSVN é possível baixar em qualquer lugar o projeto, basta clicar com o botão direito do mouse dentro de uma pasta vazia, e escolher a opção “SVN Checkout” do menu de contexto.

Conforme o projeto for evoluindo é só atualizar o fonte, para isso clique com o botão direito do mouse dentro da pasta e escolha “SVN Update”.

Quem tem uma licença do VS.Net, pode baixar aqui o Team Explorer, ele não vai funcionar com as versões Express, infelizmente!

Para quem quer saber mais sobre o Subversion e Tortoise , saiu uma matéria na edição 07 de Fevereiro/Março da Mundo.Net, e aqui você pode baixar um livro sobre o Subversion.

Próximo post vou começar a desenvolver o aplicativo e vou começar a falar de uma maneira de desenvolver usando objetos de negócio acessando o banco de dados sem o uso de Dataset’s!