Capítulo 3

No capítulo anterior criamos as classes e os mapeamento O/R do Hibernate. Vimos que essas classes farão o papel de transferir dados entre as camadas. Neste capítulo vamos construir os DAOs, ou seja, os componentes que farão acesso ao banco de dados.

Vamos falar um pouco sobre alguns detalhes importantes neste processo. No capítulo anterior indicamos um material sobre conhecimentos preliminares em relação ao Hibernate. Importante ter lido antes de continuar.

Nunca tive muita afinidade com a arquitetura cliente/servidor. Aquela onde existe um servidor de banco instalado em algum lugar da rede e as aplicações acessam diretamente este servidor fazendo requisições e persistindo dados. Esse processo é muito comum em Delphi e Visual Basic. Os programadores constroem um executável, embuntindo as regras de negócio e os comandos SQL no programa. Sempre achei isso meio complicado de gerenciar. E, de certa forma, é mesmo. Controle de transação, travamento de linhas, várias máquinas com o mesmo executável instalado e acessando o mesmo banco, etc. passam a ser preocupações do desenvolvedor que deve embutir soluções no programa. Mesmo usando o Delphi eu preferia separar alguns papéis. Eu fazia assim: a aplicação era responsável apenas por solicitar e exibir dados. As regras de negócio eram de responsabilidade das procedures do banco. Operações de incluir, alterar e excluir dados (regras de negócio e DAO) eram realizadas pelas procedures. Nenhuma aplicação poderia efetuar inserções, alterações ou deleções diretamente nas tabelas. Essas operações tinham que passar pelas procedures. As aplicações parametrizavam dados e passavam para as procedures. A aplicação permanecia aguardando o final da execução da procedure para saber se houve algum problema ou tudo foi realizado com sucesso. Nas procedures eram definidas as regras da aplicação: validações, integridades, restrições, procedures paralelas (não gosto de triggers), etc. Inclusive, até hoje, acho essa arquitetura com procedures muito boa e produtiva. Um dos motivos é a performance. Não existe nada mais rápido pra banco de dados do que procedures. Eu disse NADA!!!!!!!!

Como não existe nada que seja perfeito, essa arquitetura tem um problema: se mudar a aplicação para outro banco, as procedures terão que ser reescritas!!!! Eu tinha uma aplicação mediana em SQL Server com mais de 200 procedures e que teria que migrar para Oracle. Sem chances de reescrever as procedures novamente. E se tivesse que mudar pra outro banco, novamente? Reescrever tudo outra vez?!

Neste cenário entrou o Hibernate! Com ele foi possível ganhar indepêndencia de banco de dados. Mas nem tudo são flores. As procedures do banco geram pouco tráfego de rede. O Hibernate gera auto nível de tráfego. Por isso é importante ter cuidado ao utilizá-lo. Sem falar em outras situações: gerenciamento de sessão, conectividade com outros bancos, HQL (o SQL do Hiberante), configurações, etc. Por tudo isso é importante planejar bem o seu uso. Dediquei um pouco do meu tempo a pesquisar e planejar. Construí uma biblioteca que gerencia inúmeras situações que acabam sendo recorrentes nas aplicaçãoes com Hibernate. Eu a chamei de Regisoft.Camadas. Ela faz parte de um pacote (Regisoft Library.NET) que inclui outras bilbiotecas de nossa autoria e que utilizo no processo de desenvolvimento de sistemas de informação. Veja algumas classes que a biblioteca Regisoft.Camadas possui:

  1. NHibernateHelper – (Regisoft.Camadas.NHibernateHelper) Responsável por configurar e gerenciar o NHibernate dentro da aplicação. Inicialização das classes de mapeamento, gerenciamento da sessão, conectividade com um ou vários bancos de dados ao mesmo tempo são algumas das responsabilidades desta classe. Não precisa ser instanciada nem utilizada diretamente. Uma outra classe chamada BaseDAO fará uso desta classe internamente.
  2. BaseDAO – Todos os DAOs devem herdar dessa classe abstrata. É um DAO genérico que é responsável por dar suporte, através de seus métodos e propriedades, às operações envolvendo persistência: inserções, alterações, exclusões, transações, seleção de dados, validação de campos not-null, controle de objetos persistentes e transientes, verificação de integridade antes de uma exclusão e outras mais. Existe uma versão do BaseDAO usando o Generic (Regisoft.Camdas.Generic.BaseDAO<T,ID> ) e uma versão descontinuada sem Generic (Regisoft.Camadas.BaseDAO). A versão sem Genéric existe por compatibilidade retroativa. Aplicações desenvolvidas em .NET 1.1 ou anterior utilizam esta versão (não valia a pena mudar a aplicação toda para usar Listas baseadas em Generic).

Eu utilizo esta biblioteca em TODAS as aplicações que desenvolvo. Ela me permite abstrair da problemática do NHibernate. O tempo que eu gastei estudando, planejando e testando a biblioteca foi suficiente pra não mais precisar me preocupar com isso. Em nossa aplicação da Agenda Telefônica On-Line também não vamos nos preocupar com NHibernate. Vamos gerar nossos DAOs herdando da classe abstrata dessa biblioteca. Quem desejar escrever seu próprio BaseDAO ou sua própria biblioteca fique a vontade. Tem um post aqui que fala sobre as funcionalidades básicas que todo DAO genérico tem que ter. Leia mais… Uma novidade: o nosso BaseDAO também pode ser configurado para trabalhar numa arquitetura que faz uso de um ou mais servidores de aplicações. Clique aqui e saiba mais sobre essa possibilidade. Outra novidade é a classe NativeDAO. Esta nova classe foi criada para dar suporte as aplicações que utilizam SQL nativo em lugar do NHibernate. Usar SQL nativo tem suas vantagens. Mas isso é outro assunto que poderemos discutir em outro post ou série de posts. Quem desejar saber mais sobre esse assunto, pode deixar um comentário ou mandar um email.

Mas voltando a nossa aplicação, as DLLs da Regisoft Library.NET comentadas até aqui pode ser encontradas no local onde foi instalado o RSClass – Gerador de Classes. Utilizando a biblioteca acima não precisaremos escrever manualmente um DAO para cada tabela do banco. Podemos utilizar o RSClass – Gerador de Classes para gerar os arquivos necessários. E vamos fazer isso agora. No post anterior fizemos a configuração do projeto e geramos os arquivos de mapeamento (.cs e .hbm.xml). Neste post vamos repetir o processo utilizando outra opção para gerar os arquivos de acesso a dados do sistema (DAOs). Não será necessário refazer as configurações já que o RSClass – Gerador de Classes guarda essas informações.

Gerando as interfaces e os DAO’s

Abra o RSClass – Gerador de Classes, conecte com o projeto, selecione todas as tabelas e marque a opcão ‘DAOs’ na tela principal. Ficou assim::

Clique em ‘Gerar Classes‘. Note no progresso de gerar as classes, além dos DAOs, as Interfaces correspondente a cada DAO também está sendo gerada.

Gerando o DAOFactory e IDAOFactory

O que é isso? Um fabricador de DAO. Como já sabemos, a camada de negócio acessa a camada de dados. Mas esse acesso não é indiscriminado. O acesso é feito por um único meio. É como se o DAOFactory estivesse na porta de entrada da camada de dados. Toda vez que a camada de negócio quiser os serviços de algum DAO, terá que solicitar ao o porteiro (DAOFactory) e ele que vai acionar o DAO solicitado, instanciando-o e disponibilizando para o solicitante. O interessante desse processo é que, pela sua característica, ele pode estar em máquina diferente da camada de negócio, em um cenário de processamento distribuido. Para criar o DAOFactory e sua interface basta marcar a opcão correspondente:

Com este procedimento dois novos arquivos foram criados: DAOFactory.cs no projeto AgendaTelefonica.DAO e IDAOFactory na pasta DAO do projeto AgendaTelefonica.Interface.

Finalmente, podemos voltar ao Visual Studio.

No Visual Studio

Com os arquivos gerados nas suas respectivas pastas precisamos agora inclui-los em seus projetos. O Visual Studio precisa reconhecê-los como parte do projeto. Os passos a seguir devem ser efetuados em cada projeto do Visual Studio, no local onde os arquivos foram gerados.

  1. Selecione o projeto. Se os arquivos gerados não tiverem aparecendo clique no botão “Show all Files” do Soluction Explorer. Depois selecione os arquivos, clique em qualquer dos arquivos com o botão direito do mouse e selecione a opção “Include In Project“. Estes passos são idênticos ao que fizemos com os arquivos de mapeamentos. Detalhe: basta incluir os arquivos no projeto não deve mudar a ‘Build Action’ para ‘Embebed Resource’ desses arquivos. Isso só precisou ser feito nos arquivos .hbm.xml.

Chegou a hora de adicionar referência nos projetos às bibliotecas necessárias. Essas bibliotecas estão na pasta de instalação do RSClass.

  1. Projeto AgendaTelefonica.DAO: Clicando com o botão direito do mouse sobre o projeto selecione “Add Reference…“. Selecione a aba Browse e localize os arquivos Regisoft.Camadas.dll, Regisoft.dll, Regisoft.Camadas.Interface.dll e Microsoft.Practices.Unity.dll presentes na pasta de instalação do RSClass – Gerador de Classes. Selecione-as e clique em Ok.
  2. Projeto AgendaTelefonica.Interface: Clicando com o botão direito do mouse sobre o projeto selecione “Add Reference…“. Selecione a aba Browse e localize as bibliotecas Regisoft.dll e Regisoft.Camadas.Interface.dll (não inclua neste projeto Regisoft.Camadas.dll e Microsoft.Practices.Unity.dll) presentes na pasta de instalação do RSClass – Gerador de Classes. Selecione-as e clique em Ok.

Se tudo foi feito como indicado o Solution Explorer estará como abaix0, quando apresentar as referências dos projetos AgendaTelefonica.DAO e AgendaTelefonica.Interface.

Tecle Ctrl+F5 para montar o projeto. Se nenhum erro ocorrer voce concluio com sucesso essa etapa. No máximo, voce receberá uma mensagem informando que não há nenhum projeto que possa ser executado.

Vamos agora analisar os arquivos gerados.

  1. Abra primeiro o arquivo CidadeDAO.cs. Veja que não existe nada de extraordinário nele. Apenas 03 construtores, um método que sugere a listagem de cidades pela UF e outro método que filtra os dados pela descrição. Um ponto de destaque é a definição da classe que herda de BaseDAO<Cidade,long> e uma interface ICidadeDAO. A BaseDAO é a classe que implementa as funcionalidades de persistências que já estão prontas para serem usadas. Como é uma classe genérica estamos usando <Cidade,long> que diz que o DTO (ou classe de mapeamento OR) a que esta classe se refere é ‘CIDADE’ e diz também que possui um campo chave primária do tipo ‘long’. É provável que precisemos de algumas novas funcionalidades na classe CidadeDAO.cs e podemos adiciona-la depois, quando necessário. Os principais métodos – inclusão, exclusão, alteração, seleções de dados, transações, etc. – já estão disponíveis pela herança. Inclusive, os dois métodos de listagem são implementados utilizando recursos internos da BaseDAO. Abra também a classe ICidadeDAO.cs e veja que lá também não existe nada extraordinário. Apenas as herança de outra interface genérica e a assinatura de um método presente na classe CidadeDAO.
  2. Abra agora o arquivo DAOFactory.cs. Como já falamos, este será o arquivo por onde as regras de negócio farão acesso aos DAOs. Voce entenderá isso melhor quando trabalharmos na geração dos BOs. Veja que também possui uma inteface na sua declaração. Graças a sua estrutura, é possível planejar este sistema para executar banco de dados, DAOs, regras de negócio e aplicativo web em máquinas diferentes. Isso será discutido futuramente na sequência deste tutorial. Por hora, voce deve entender que os DAOs fazem acesso ao banco de dados da aplicação e que é o factory dos DAOs que possibilita o acesso a eles. Mas abaixo no arquivo voce vê exatamente os construtores dos DAOs sendo chamados.
  3. No DAOFactory voce deve ter notado a presença de uma classe chamada UnityContainer trabalhando no construtor dos DAOs. Ela está sendo usada para realizar procedimentos chamados injeção de dependência e inversão de controle. Faz parte de um conjunto de boas práticas de programação e vale a pena pesquisar para entender melhor esses conceitos. Essa classe pertence a um framework de injeção de dependência criado pela Microsoft. Para saber mais acesse http://unity.codeplex.com. Voce vai voltar a vê-la quando falar-mos sobre geração das classes de regra de negócio. Para nossa arquitetura basta saber que ela existe. Seu uso já foi testado e aprovado.

Estude bem este processo e os arquivos gerados. No próximo capítulo vamos gerar os BOs com suas interfaces. O procedimento é similar ao utilizado na geração dos DAOs e suas interfaces. Inclusive, fique a vontade para tentar fazer sozinho. Estamos abertos a dúvidas e sugestões. Na pasta de instalação do RSClass – Gerador de Classes voce pode encontrar os arquivos deste tutorial gerados até aqui (PARTE IV).

Se voce gostou e deseja ter os fontes da Regisoft Library ou de qualquer outro projeto nosso clique aqui e saiba como adquiri-los. Você certamente estará ajundando a manter este trabalho.

Anúncios