Aplicação do Padrão Data Access Object (DAO) em Projetos Desenvolvidos com Delphi

Transcrição

1 Aplicação do Padrão Data Access Object (DAO) em Projetos Desenvolvidos com Delphi Marcelo Sardagna 1, Adilson Vahldick 1 1 Departamento de Sistemas e Computação Universidade Regional de Blumenau (FURB) Blumenau, SC Brasil msardagna@gmail.com, adilsonv77@gmail.com Trabalho de Graduação Resumo. Este artigo apresenta uma proposta para utilização do padrão Data Access Object em aplicações desenvolvidas com Delphi utilizando os componentes DBExpress. Em seguida descreve uma ferramenta desenvolvida para alterar o código fonte em arquivos PAS e DFM de aplicações legadas em Delphi para empregar essa proposta de utilização do padrão. Abstract. This work presents a proposal for utilizing Data Access Object pattern at Delphi applications with DBExpress components. Next describes a tool developed to modify the source code in PAS and DFM files from legacy applications in Delphi for utilizing the pattern propose in this work. 1. Introdução O ambiente de desenvolvimento Delphi é um ferramental que permite o desenvolvimento rápido de aplicações, pois ele se baseia em arrastar componentes para a janela, criar ligações entre esses componentes e alterar suas propriedades. O sucesso do Delphi se deve à pouca exigência técnica dos programadores para desenvolver uma aplicação, pois a maior parte do trabalho é esse arrastar e conectar os componentes. A necessidade de programar linhas de código é minimizada com a possibilidade de codificar todas as regras de negócio na própria janela onde foram arrastados os componentes. Por outro lado, a rapidez e a facilidade em desenvolver as aplicações dessa maneira traz sérios problemas na manutenibilidade. A reusabilidade é baixa pois o código é programado na própria janela e o também devido ao alto acoplamento, pois os componentes são todos atrelados à janela. No Delphi costuma-se programar nas próprias janelas, logo, a reusabilidade, quando acontece, é de janelas e não de regras de negócio. Entretanto, o Delphi permite o desenvolvimento orientado a objetos, onde podem se programar as regras de negócios em classes, ou mesmo em componentes, e conectar esses objetos nas janelas aumentando o nível de reusabilidade. Contudo, quem inicia com Delphi, se encanta com as facilidades proporcionadas pelo ambiente e somente se depara com os problemas de manutenção num segundo momento, quando o cliente solicita mudanças nos requisitos, ou se deseja aproveitar um projeto para outros clientes.

2 Uma das situações que pode se notar a baixa reusabilidade é quanto à conexão com banco de dados. As expressões SQL são informadas diretamente nos componentes, seja nas janelas ou num Data Module. As mudanças no projeto do banco de dados exigem acessar componente a componente e alterar as expressões para atender essas alterações. Na última década tem-se dedicado esforços no estudo e disseminação dos padrões de projeto para aumentar a reusabilidade de software e por consequência diminuir o custo de manutenção. Segundo Gamma et al (2000), Valente (2003), Shalloway e Trott (2004) e Fowler (2006), os padrões de projeto permitem a reutilização de arquiteturas e projetos bem sucedidos, reaproveitando soluções e a experiência dos modeladores, assim como estabelecendo um vocabulário comum para os envolvidos no desenvolvimento melhorando a comunicação entre eles. Além disso, a adoção de padrões requer adaptação dos projetos, e com isso naturalmente as aplicações precisam serem bem arquitetadas para tal reaproveitamento, criando assim um ciclo virtuoso entre a nova aplicação e os padrões já adotados por um equipe. Na busca de uma solução para melhorar a manutenibilidade das aplicações em Delphi quanto à conexão de banco de dados é proposto neste trabalho uma estratégia de adoção do padrão de projetos Data Access Object (DAO), que abstrai e encapsula os mecanismos de acesso a banco de dados (AECE, 2005), adaptado na utilização de componentes DBExpress. Também é demonstrada a ferramenta implementada para empregar essa estratégia em aplicações Delphi legadas. Esse artigo é estruturado da seguinte forma: primeiro é apresentada uma breve fundamentação sobre o padrão DAO, para em seguida apresentar os componentes Delphi considerados nesse trabalho; na seção seguinte é apresentada a estratégia de utilização do padrão DAO em aplicações Delphi; na seção subsequente é demonstrado a ferramenta implementada para alterar projetos em Delphi para utilizar o padrão; e por último são apresentadas as conclusões em relação ao estudo feito nesse trabalho. 2. Data Access Object (DAO) O padrão DAO consiste em abstrair o mecanismo de persistência utilizado na aplicação. A camada de negócios acessa os dados persistidos sem ter conhecimento se os dados estão em um banco de dados relacional ou um arquivo XML. O padrão DAO esconde os detalhes da execução da origem dos dados (SUN, 2007).

3 Figura 1 Estrutura do padrão DAO A figura 1 apresenta a estrutura do padrão DAO. A classe DataAccessObject encapsula o acesso aos dados, que por sua vez é mantido pela classe DataSource que pode ser um arquivo XML, uma base de dados ou algum serviço remoto, ou seja, a origem dos dados. A classe BusinessObject representa a aplicação, ou também conhecido como cliente do padrão, que usa um objeto DataAccessObject. Ao utilizá-lo a classe cliente recebe ou envia um objeto TransferObject. Esse objeto contém os dados a serem enviados ou trazidos da origem dos dados. Exemplificando com uma aplicação real, uma classe ProdutoDAO (que faz o papel de DataAccesObject) pode ser responsável pelo acesso aos dados do cadastro de produtos. Um produto desse cadastro pode ser representado por uma classe Produto (que desempenha o papel de TransferObject). A classe ProdutoDAO pode ter um método para leitura que recebe um chave, busca o produto na origem de dados (que pode ser um banco de dados), cria um objeto Produto com os dados do produto e devolve esse objeto à aplicação. A classe ProdutoDAO pode ter um método para salvar que recebe como parâmetro um objeto Produto e com essas informações inclui ou altera um produto na origem dos dados. 3. Componentes DBExpress O pacote de componentes DBExpress está disponível a partir da versão 7.0 do Borland Delphi e permite acesso aos banco de dados sem necessidade de configuração ou aplicações adicionais no Windows, como acontecia nas versões anteriores (BORLAND, 2005). A conexão e o acesso com os bancos de dados é feito com as próprias DLLs fornecidas pelos fabricantes dos SGBDs. Os componentes DBExpress abstraem e encapsulam o acesso ao banco de dados, mas não podem ser considerados a aplicação do padrão DAO na sua forma mais pura, pois eles não utilizam objetos TransferObject. Os dois principais componentes são o TSQLConnection e TSQLQuery. No componente TSQLConnection se configura o banco de dados, ou seja, qual a DLL e por consequência, qual o SGBD a ser acessado. O componente TSQLQuery é responsável pelo acesso aos dados e é nesse componente que o programador insere as expressões SQL. Ambos os componentes abstraem para o implementador detalhes do banco de dados, ou seja, os componentes fazem o acesso à DLL enviando as expressões SQL e devolvendo os resultados dessas execuções. 4. Padrão DAO com DBExpress O objetivo de definir uma estratégia para utilização do padrão DAO nesse trabalho é permitir que as expressões SQL sejam concentradas em classes DataAccessObject, e não espalhadas pelas janelas como acontece convencionalmente. Pretende-se aqui definir como funcionarão as classes DataAccessObject e TransferObject. O papel de DataSource será desempenhado pelos dois componentes DBExpress comentados na seção anterior. A conexão com o banco é desempenhada pelo componente TSQLConnection, e normalmente existe um único objeto desses na aplicação toda, pois o tempo e a quantidade de recursos alocados para conexão é

4 considerável e limitada. Por essa razão, cada classe DataAccessObject receberá como parâmetro no construtor um objeto TSQLConnection que será guardado num atributo. Como os componentes visuais são associados com componentes DataSource (classe do pacote DataAccess), e esse componente pode ser associado com componentes TSQLQuery, definiu-se que os métodos de leitura devem receber como parâmetro um objeto TSQLQuery, e popular seu atributo SQL. Com isso, a classe aqui proposta não fornece objetos TransferObject. A figura 2 demonstra um exemplo de um método de leitura de dados. function TFORNECEDORDADO.SelecionarFornecedor(FQuery : TSQLQuery; Fo_Cod: Variant): TSQLQuery; begin FQuery.SQLConnection := Conecta; FQuery.Close; FQuery.SQL.Clear; FQuery.SQL.Add( Select * From Fornecedor ); FQuery.SQL.Add( Where Fo_Cod= :Fo_Cod ); FQuery.ParamByName( FO_COD ).AsString := Fo_Cod; Result := Fquery; end; Figura 2 Exemplo de método de leitura de dados Entretanto, para os métodos de inserção, alteração e exclusão, definiu-se que deve receber um objeto TransferObject e criar um TSQLQuery dentro do próprio método, mapear o objeto TransferObject para código SQL e executar a expressão. A figura 3 apresenta um exemplo para o método de inserção. procedure TFORNECEDORDAO.Inserir(FORNECEDOR : TFORNECEDOR); var FQuery : TSQLQuery; begin FQuery := TSQLQuery.Create(Nil); try FQuery.SQLConnection := Conecta; FQuery.SQL.Clear; FQuery.SQL.Add('Insert Into FORNECEDOR'); FQuery.SQL.Add('(FO_COD, FO_DSC, FO_DSC_RED, FO_CNPJ, '+ 'FO_INSCR_EST, FO_RUA, FO_CEP, FO_CIDADE, FO_BAIRRO, FO_UF'); FQuery.SQL.Add('Values'); FQuery.SQL.Add('(:FO_COD,:FO_DSC,:FO_DSC_RED, :FO_CNPJ, '+ ':FO_INSCR_EST,:FO_RUA,:FO_CEP,:FO_CIDADE,:FO_BAIRRO,:FO_UF )'); FQuery.ParambyName('FO_COD').AsInteger := FORNECEDOR.FFO_COD; FQuery.ParambyName('FO_DSC').AsString := FORNECEDOR.FFO_DSC; FQuery.ParambyName('FO_DSC_RED').AsString := FORNECEDOR.FFO_DSC_RED; FQuery.ParambyName('FO_CNPJ').AsString := FORNECEDOR.FFO_CNPJ; FQuery.ParambyName('FO_INSCR_EST').AsString := FORNECEDOR.FFO_INSCR_EST; FQuery.ParambyName('FO_RUA').AsString := FORNECEDOR.FFO_RUA; FQuery.ParambyName('FO_CEP').AsString := FORNECEDOR.FFO_CEP; FQuery.ParambyName('FO_CIDADE').AsString := FORNECEDOR.FFO_CIDADE; FQuery.ParambyName('FO_BAIRRO').AsString := FORNECEDOR.FFO_BAIRRO; FQuery.ParambyName('FO_UF').AsString := FORNECEDOR.FFO_UF; FQuery.ExecSQL; finally FreeAndNil(FQuery); end; end; Figura 3 Exemplo de método para inserção As próximas figuras exemplificam a utilização desses métodos numa aplicação real. A figura 4 apresenta dois trechos de código de como seria incluir e buscar fornecedores sem utilização do padrão. As expressões SQL dos componentes QueryInsereFornec e QueryBuscaFornec da figura 4 são atribuídos uma única vez

5 diretamente durante a edição da form. A figura 5 apresenta as mesmas operações utilizando o padrão DAO. With QueryInsereFornec do begin ParamByName('FO_DSC').AsString := ednome.text; ParamByName('FO_DSC_RED').AsString := ednomefantasia.text; ParamByName('FO_CNPJ').AsString := edinscrest.text; ParamByName('FO_INSCR_EST').AsString := edcnpj.text; ExecSQL; With QueryBuscaFornec do begin Close; ParamByName('FO_COD').AsInteger Open; := strtoint(edcodigo.text); Figura 4 Exemplo de código fonte para inserir e buscar fornecedores With QueryInsereFornec do Begin Fornec := TFornecedor.create; Fornec.FO_DSC := ednome.text; Fornec.FO_DSC_RED := ednomefantasia.text; Fornec.FO_CNPJ := edinscrest.text; Fornec.FO_INSCR_EST := edcnpj.text; FornecDAO.Inserir (Fornec); FornecDAO.SelecionarFornecedor(QueryBuscaFornec, strtoint(edcodigo.text)); QueryBuscaFornec.Open; Figura 5 Exemplo de inserção e busca de fornecedores utilizando padrão DAO 5. Ferramenta Aplicadora do Padrão DAO em Projetos Delphi A utilização de padrões leva a produtividade devido ao reuso e facilidade na manutenção, e uma vez de conhecimento da equipe sobre o assunto eles são facilmente empregados em novas aplicações. Com o intuito de permitir que aplicações legadas em Delphi possam ser convertidas para aplicações que utilizam o padrão DAO, foi desenvolvida uma ferramenta que interpreta e altera os projetos substituindo código fonte tanto em arquivos PAS quanto DFM. A ferramenta foi desenvolvida na forma de assistente, isto é, cada passo na conversão é dividida numa página e todas contendo um botão para ir à próxima fase. O código a ser gerado e as alterações no projeto acontecem somente no final. As fases na aplicação do padrão são as seguintes: 1. identificação do projeto e do banco de dados: nesse momento o usuário informa o local onde está armazenado o projeto em Delphi, qual a pasta de destino do projeto convertido (com isso o projeto original é mantido) e qual o banco de dados a ser considerado; 2. identificação das tabelas a serem aplicadas o padrão DAO: baseado no banco de dados informado na fase anterior, a ferramenta apresenta todas as tabelas que pertencem a esse banco, para que o usuário selecione quais são as tabelas que devem ser consideradas na aplicação do padrão. Com isso, a ferramenta mapeará uma classe DataAccessObject e uma TransferObject relativa a cada tabela. A

6 classe DataAccessObject conterá os métodos para inserir, alterar, excluir e selecionar todos os registros. A classe TransferObject conterá um atributo para cada coluna da tabela; 3. análise dos arquivos PAS e DFM: nessa fase a ferramenta analisa cada arquivo do projeto procurando pelos componentes TSQLQuery. São considerados somente os componentes arrastados para as janelas. Para esses componentes são procurados pelas expressões SQL associadas a eles. Uma vez localizada a expressão, ela é classificada quanto a natureza do operação (INSERT, UPDATE, DELETE ou SELECT) e a tabela envolvida. A informação da tabela determina a classe DataAccessObject a ser considerada. Em seguida cada expressão SQL deve gerar um método nessa classe. Toda vez que é encontrada uma expressão SQL é primeiramente verificado se ela já foi mapeada para um método, ou seja, se já foi identificada essa expressão em outro momento. Com isso evita-se métodos duplicados na classe DataAccessObject. As expressões SELECT que envolvem mais de uma tabela fazem com que a ferramenta mapeie uma nova classe DataAccessObject sendo batizada com a união do nome de todas as tabelas envolvidas na expressão; 4. nomear métodos das classes DataAccessObject: após a análise de todos os arquivos são apresentados ao usuário todas as classes que serão geradas, e métodos identificados para cada classe, junto da expressão SQL que originou a necessidade do método e as units em que ela foi identificada. Nessa fase o usuário pode alterar o nome do método a ser gerado, pois a regra de batismo da ferramenta é baseada na natureza da operação (InserirXXX, AlterarXXX, ExcluirXXX e SelecionarXXX, onde XXX é o nome da tabela) e mais um número sequencial. Por exemplo, a ferramenta pode ter detectado vários comandos SELECT (o que é bem natural) para a tabela de pedidos e o nome dos métodos seriam SelecionarPedido1, SelecionarPedido2 e assim por diante. Esses nomes não são muito sugestivos sobre o objetivo do comando de seleção, e por essa razão a ferramenta permite que os métodos sejam rebatizados. A figura 6 apresenta a tela capturada da ferramenta relativa a essa fase e a figura 7 mostra a janela onde pode se alterar o nome de um método; 5. geração do código e substituição dos arquivos PAS e DFM: essa é a última fase do processo. Para os arquivos DFM são eliminadas as expressões SQL dos componentes TSQLQuery e criado um método FormCreate (se ainda não existia) na janela com a inicialização das expressões através da classe DataAccessObject. Para os arquivos PAS, as linhas de código com as expressões SQL são eliminadas e substituídas por chamadas aos métodos das classes DataAccessObject, da forma como já foram ilustrados nas figuras 4 e 5. Após a execução dessas fases o novo projeto estará funcional e utilizando o padrão DAO. Qualquer mudança no projeto do banco de dados e que exiga alterações no projeto Delphi devem ser feitas diretamente nas classes DataAccesObject.

7 Figura 6 Janela com a fase 4 da ferramenta Figura 7 Janela para alteração do nome do método

8 6. Conclusões A aplicação de padrões de projeto eleva o nível de qualidade no produto final. Após experimentar a ferramenta descrita nesse trabalho numa aplicação real percebeu-se que o código gerado permite facilidade em sua manutenção, pois eliminou a redundância, e concentrou todo o código SQL em classes específicas. Devido à forma como os programadores Delphi estão habituados a desenvolverem as aplicações através de usar muito componentes, sugere-se que qualquer nova técnica ou idéia para melhorar o desenvolvimento de aplicações nessa linguagem inclua a utilização de componentes. Outro ponto importante a ressaltar, é que a prática de novas técnicas e paradigmas de desenvolvimento considerem a aplicações legadas. Existe muito código no Brasil produzido com Delphi, inclusive com versões anteriores à 7.0, e um fator motivante de novidades é que sejam compatíveis com o que já faça parte do portfólio da equipe de desenvolvimento. O texto apresentado nesse artigo levou em consideração esses dois pontos: propôs idéias para a adoção do padrão de projeto DAO usando componentes DBExpress, e descreveu uma ferramenta para que aplicações legadas possam usufruir dessas idéias. Referências Aéce, I. (2005) Analisando o Microsoft PetShop 3.0. São Paulo. Disponível em: < Acesso em: 07 abr Borland Software Corporation. (2005) Borland Delphi for Microsoft Windows: help. Version Fowler, M. (2006) Padrões de arquitetura de aplicações corporativas. Gamma, E. et al (2000) Padrões de projeto: soluções reutilizáveis de software orientado a objetos. Valente, L. (2003) Design patterns: padrões para projetos.. 24 f. Dissertação (Mestrado em Computação)-Universidade Federal Fluminense, Niterói. Disponível em: < Acesso em: 07 abr Shalloway, A.; Trott, J. (2004) Explicando padrões de projeto: uma nova perspectiva em projeto orientado a objeto. Sun. (2007) Core J2EE patterns: data access object. Disponível em: < Acesso em: 15 abr. 2007