Persistência de Dados Utilizando os Padrões DAO e ORM

IGOR LUCIANO DE LIMA MOREIRA

PERSISTÊNCIA DE DADOS UTILIZANDO OS PADRÕES DAO(DATA ACCESS OBJECT) E ORM(OBJECT RELATION MAPPED)

INCONFIDENTES-MG 2013

IGOR LUCIANO DE LIMA MOREIRA

PERSISTÊNCIA DE DADOS UTILIZANDO OS PADRÕES DAO(DATA ACCESS OBJECT) E ORM(OBJECT RELATION MAPPED)

Trabalho sobre os padrões DAO e ORM apresentados pela disciplina de Linguagem de Programação III com requisito para obtenção de nota.

Orientador: Ivan Paulino Pereira

INCONFIDENTES-MG 2013

SUMÁRIO 1. INTRODUÇÃO ............................................................................................................................... 1 2. DESENVOLVIMENTO................................................................................................................... 2 2.1.1 Conceitos e Definições............................................................................................................ 2 2.1.2 Aplicações ............................................................................................................................... 2 2.1.3 Vantagens e Desvantagens do Padrão DAO ........................................................................... 4 2.1.4 Exemplos ................................................................................................................................. 6 .......................................................................................................................................................... 6 2.2.1 Conceitos e Definições............................................................................................................ 7 ORM : Object Relational Mapper .................................................................................................... 7 2.2.2 Aplicações ............................................................................................................................... 7 2.2.3 Vantagens e Desvantagens ...................................................................................................... 7 2.2.4 Exemplos ................................................................................................................................. 8 3.CONCLUSÃO .................................................................................................................................. 9 4.REFENRÊNCIAS BIBLIOGRÁFICAS ......................................................................................... 10 5.GLOSÁRIO .................................................................................................................................... 11

I

1. INTRODUÇÃO Com o passar do tempo não existe dúvidas que o paradigma de programação mais usado na produção de sistemas é o Orientado a Objetos. Hoje as empresas usam grandes bancos de dados que manipulam milhões de informações. Não se pode conceber um sistema moderno sem acesso a algum tipo de base de dados.

Dessa forma, os nossos programas devem saber se comunicar com a base de dados. Como fazer isso de maneira adequada? Uma alternativa muito viável é usar o pattern DAO. Porém em contra partida, o mecanismo de armazenamento persistente mais utilizado ainda são os sistemas de gerenciamento de banco de dados relacional. Este fator impulsionou o surgimento do conceito do mapeamento objeto relacional ORM. Enfim no decorrer dos anos, os frameworks ORM em java foram surgindo dia após dia com o objetivo de oferecer genericamente esta camada intermediária entre a aplicação e o SGBD, minimizando tempo, esforço, custo etc. Fato é que o conceito ORM e as opções de frameworks entraram em proporções enormes, transformando-se de uma simples camada para uma decisão não trivial e amplamente complexa.

1

2. DESENVOLVIMENTO 2.1 O Padrão Data Access Object (DAO)

2.1.1 Conceitos e Definições Objeto de acesso a dados (ou DAO, acrônimo de Data Access Object), é um padrão para persistência de dados que permite separar regras de negócio das regras de acesso a banco de dados. Numa aplicação que utilize a arquitetura MVC, todas as funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos Java para tipos de dados SQL ou executar comandos SQL, devem ser feitas por classes de DAO. Deste modo, DAO funciona como um intermediário entre os mundos, um conjunto de tags dispostas de modo hierárquico, contendo informações estruturadas. Arquivos texto são um conjunto de caracteres. Bancos de dados relacionais são um conjunto de tabelas, colunas, e linhas.

Aplicações Java são um conjunto de objetos.

O DAO deve funcionar como um tradutor dos mundos. Suponha um banco relacional. O DAO deve saber buscar os dados do banco e converter em objetos para ser usado pela aplicação.

Semelhantemente, deve saber como pegar os objetos, converter em instruções SQL e mandar para o banco de dados. É assim que um DAO trabalha.

2.1.2 Aplicações A maioria das aplicações de nível corporativo usam algum tipo de persistência de dados.

Entre eles o mais usado é o Banco de Dados e a linguagem SQL é amplamente utilizada para comunicar com os sistemas gerenciadores de banco de dados. Java suporta esta necessidade desde cedo com o advento da API JDBC (Java Database Connectivity).

Com o padrão DAO visavam originalmente encapsular os conjuntos de códigos SQL que existiam em aplicações legada herdada das. Esse código continha regras tanto na pesquisa dos dados, tanto na edição dos dados. É comum ao inserir um determinado dado, ter que inserir ou atualizar outros.

Quando se faz uso em um projeto do padrão DAO primeiramente é por que existe a necessidade em separar as regras de negócios das regras de persistência de dados. O objetivo principal disto é promover o isolamento entre classes de objetivos distintos (persistência/negócio/interface) e a flexibilidade quando se deseja, por exemplo, utilizar diferentes SGBDs. Quando não se fazia uso do padrão DAO, as aplicações eram codificadas de forma que as deixavam dependentes de um único banco de dados. Assim havia dificuldades como migrar o sistema e alterar parte do código relacionado a operações de CRUD e ainda existia uma forte dependência entre classes de negócios com classes de persistência. O padrão DAO surge como solução para esses problemas de uma forma bem simples.

2

Com ele todas as regras do mecanismo de persistência passam a ser mediadas por um objeto do tipo DAO. Todas essas classes e interfaces devem seguir o padrão de nomenclatura “XxxxDAO”, onde o prefixo “Xxxx” faz referência ao nome da classe de entidade que será persistida e o sufixo “DAO” indica que esta classe se refere a uma classe de persistência que utiliza o padrão Data Access Object.

Dao apresenta-se versátil em suas múltiplas vertentes de utilização, de tal modo que antes de começarmos devemos ter uma maneira de utilizar. Caso utilize-se um framework de injeção de dependência (DI), ou utilizando o padrão Factory, ambos antagonistas entre si.

Assim antes devemos atentar para qual vertente dos “Sabores DAO “devemos focar.  DAO genérico: Ao usar tipo DAO genérico é errado dizer que diminuiria quantidade de interfaces e implementações necessárias. Isso é errado, pois interfaces do DAO contêm métodos de procura específicos dependentes do objeto de transporte, das regras de persistência e de regras de negócio.

Usando tipos genéricos neste estágio não nos ajuda a diminuir o número de classes ou simplificar a implementação mas no ajuda a diminuir o número de métodos por interface.  DAO com Bridge: Deixar que objetos de transporte sejam explicitamente classes é um problema, pois todas as implementações do DAO para as várias tecnologias estão forçadas a utilizar o mesmo objeto. Se o objeto mudar (por exemplo, adicionarmos um campo) todas as implementações de DAO para as várias tecnologias têm que mudar. Para evitar este problema aplicamos o padrão Bridge deixando as implementações e as interfaces serem definidas independentes. Para isso utilizamos interfaces em vez de classes para especificar os nossos objetos de transporte.  DAO com Bridge com Proxy Como não existe nenhuma outra lógica nos objetos de transporte que não seja ler e escrever os seus atributos podemos utilizar uma implementação genérica baseada num mapa atributo= valor utilizando o padrão Proxy. Basicamente utilizamos um Map e o encapsulamos dinamicamente na interface do objeto de transporte esperado. Isto é relativamente simples de fazer utilizando a classe java.lang.reflect.Proxy da API padrão do JSE. A utilização do padrão Bridge não nos ajuda a diminuir classes, mas ajuda na implementação. Podemos ter controle total sobre como implementamos os objetos DAO e como comunicamos com a API de persistência. Isso permite que utilizemos otimizações, entre as quais o uso de Proxy para os objetos de transporte. Retirando efetivamente da aplicação o trabalho de os codificar e manter.  DAO com Metadados Para reduzir o número de implementações necessárias, ou pelo menos diminuir a implementação de métodos comum é necessário termos a informação descrita de uma forma mais abstrata. Temos que utilizar metadados.

Existem dois tipos de metadados que podem ser usados, não necessariamente excludentes.

3

Podemos utilizar metadados existentes na própria estrutura das classes. Este uso é normalmente referido como Introspecção (Introspection é um tipo particular de Reflection) Por exemplo, não usar new na classe e usar os mecanismos de do Java para criar o objeto a partir da sua classe. Outro exemplo é utilizar introspecção para ler e escrever os atributos dos objetos dinamicamente invocando os métodos get/set dinamicamente. Para que o mecanismo de introspecção funcione a implementação do DAO precisa previamente saber a classe do TO. Outra forma de metadados são aqueles relacionados à estrutura persistente do objeto.

No caso de bancos de dados seriam os metadados das tabelas e seus relacionamentos. Podemos deixar à responsabilidade da implementação do DAO descobrir e utilizar os metadados. Uma melhor opção é utilizar o padrão MetadataMapper deixando essa responsabilidade para outro objeto. Este objeto pode simultaneamente obter informações da estrutura de classes como ser configurado com informações extra sobre relacionamentos e tabelas.  DAO com QueryObject: Aquilo que separa ainda de implementações ainda mais genéricas para o padrão DAO são os métodos especiais de pesquisa. Criar um método para cada estratégia de pesquisa aumenta rapidamente a interface do DAO. Isso é mau pois estamos aumentando a responsabilidade dos implementadores da interface. Isso obriga a que todos os DAO de todos os mecanismos implementem esses métodos. Inadvertidamente podemos criar métodos que certos tipos de persistência não podem executar. Mesmo com o padrão Bridge, isso pode ser complicado de gerenciar.

Para solucionar isso podemos invocar o Principio de Separação de Responsabilidade (SoC) e abstrair a lógica de pesquisa num objeto à parte.

2.1.3 Vantagens e Desvantagens do Padrão DAO A utilização do padrão DAO, conforme já descrito em post anterior, permite encapsular e centralizar o acesso a uma fonte de dados (SINGH et al, 2002, tradução nossa). Além desta, outras vantagens em utilizar este padrão são descritas abaixo e podem ser observadas em Alur, Crupi, Malks (2003, tradução nossa), Wolff, Schmidt e Völter (2001, tradução nossa), Nock (2003, tradução nossa) e Marinescu (2002, tradução nossa): · Permite organizar a lógica de acesso a dados e encapsular características específicas para facilitar a portabilidade e facilidade de manutenção; · Diminui a complexidade dos objetos de negócio, pois passam a conter apenas a lógica do negócio, delegando ao objeto DAO as operações relacionadas à persistência; · Facilita a adoção de um novo tipo de banco de dados para a aplicação, já que a única alteração a ser realizada refere-se aos objetos DAO; · Permite desenvolver e testar toda a camada responsável pela persistência dos dados separadamente do resto da aplicação; · Facilita a incorporação de estratégias de otimização de performance, pois o acesso a banco de dados é um gargalo comum na performance de sistemas e geralmente, simples otimizações garantem um grande efeito no desempenho da aplicação. Como o acesso ao banco de dados está centralizado nos objetos DAO, é mais fácil identificar e corrigir o problema, além de 4

aplicar a otimização para todas as partes do sistema que a utilizam, realizando uma única alteração; e · Permite abstrair do programador os detalhes do mecanismo de persistência utilizado na aplicação.

No entanto, mesmo possuindo vantagens marcantes, o padrão DAO também apresenta desvantagens que são descritas abaixo e podem ser observadas em Wolff, Schmidt e Völter (2001, tradução nossa) e Nock (2003, tradução nossa): · Limita o controle de acesso a dados: Como todas as operações lógicas de acesso a dados estão definidas nos objetos DAO, toda a aplicação fica restrita a tais operações. Logo, se o DAO for mal-projetado ou não for suficientemente versátil, não atenderá os requisitos da aplicação; e Pequena redução de performance: Como um novo nível de comunicação entre os objetos foi criado, obtém-se uma pequena redução na performance da aplicação. No entanto, esta redução é mínima quando comparada a comunicação de processos entre cliente e servidor, ou até mesmo ao acesso a um banco de dados. Logo, esta redução geralmente não é percebida na performance do sistema..

5

2.1.4 Exemplos

Ilustração 1: Imagem Sérgio Taborda, Uso de QueryObject dinamização de código diminuindo o número de métodos de pesquisa específicos.

Ilustração 2: por Sérgio Taborda, método AbstractDAO

6

2.2 O Padrão Object Relational Mapper (ORM)

2.2.1 Conceitos e Definições

ORM : Object Relational Mapper ORM (Object Relational Mapper) é uma técnica de mapeamento de objeto relacional que permite fazer uma relação dos objetos com os dados que os mesmos representam. Ultimamente tem sido muito utilizada e vem crescendo bastante nos últimos anos.

2.2.2 Aplicações Você que é desenvolvedor de aplicações orientadas a objetos, sabe que de alguma maneira precisa armazenar e recuperar informações em bancos de dados relacionais. Um ORM (Object-Relational Mapping), nada mais é do que um Framework ou um conjunto de classes que permite que você faça este trabalho sem precisar escrever códigos de conexão com o banco, querys de SQL a todo momento, preservando as características de orientação a objetos da linguagem face à natureza relacional dos bancos de dados atuais.

Este crescimento, tem se dado principalmente pelo fato de muitos desenvolvedores não se sentirem a vontade de escrever código SQL e pela produtividade que esta técnica nos proporciona. Existem ótimos ORM´s como Hibernate, NHibernate, Entity Framework e etc.

2.2.3 Vantagens e Desvantagens Você escreve menos código e programa com muito mais produtividade.

- Seu código fica mais elegante.

- É mais fácil de dar manutenção no projeto.

- Melhora a padronização da sua aplicação.

7

2.2.4 Exemplos

Ilustração 3: por Cadu, Representação dos dois mundos de interação da arquitetura ORM

Ilustração 4: por Cadu, modelo de trabalho de ORM

8

3.CONCLUSÃO O padrão Data Acess Object(DAO) apresenta um mecanismo interessante para se trabalhar com a persistência dos dados, devido a premissa de remover todo o código de acesso a banco de dados do código da aplicação e assim trasportála para uma classe que possa interagir e ser responsável por ela, facilita a utilização e entendimento.

ORM (Object Relational Mapper) por sua vez, vem ganhando seu espaço e consolidação nos últimos anos até pelo fato da não familiaridade de que muitos programadores encontrar em escrever os códigos SQL. Enfim são ótimas ferramentas de desenvolvimento, assim como disputam seu lugar antagonicamente mercado. E a tendência é que essa disputa aumente nos últimos anos

9

4.REFENRÊNCIAS BIBLIOGRÁFICAS TABORDA. I. DAO. Disponível em http://javafree.uol.com.br/artigo/871452/Introducao-aopattern-DAO.html#ixzz2fEXUZVGy / Acessado em 15/09/2013.

DEVMEDIA. Disponível em http://www.devmedia.com.br/introducao-a-persistencia-comhibernate-parte-1-easy-java-magazine-4/20138 Acessado em 15/09/2013.

JAVA FREE.org. Disponível em http://javafree.uol.com.br/artigo/871452/Introducao-aopattern-DAO.html Acessado em 15/09/2013.

DEVMEDIA ORM OBJECT RELATIONAL Disponível em http://www.devmedia.com.br/orm-object-relational-mapper/19056 Acessado em 15/09/2013.

10

5.GLOSÁRIO JDBC: Java Database Connectivity ou JDBC é um conjunto de classes e interfaces (API) escritas em Java que fazem o envio de instruções SQL para qualquer banco de dados relacional.

CRUD: A sigla tem origem na língua inglesa para Create, Retrieve, Update e Delete, em português teria o significado de Criar, Recuperar, Atualizar e Excluir. São as quatro operações básicas em um banco de dados.

SGBDs: Sistema Gerenciador de Banco de Dados.

JEE: O Java Enterprise Edition é a plataforma Java voltada para redes, internet, intranet e semelhantes, sendo assim, ela contém bibliotecas especialmente desenvolvidas para o acesso a servidores, a sistemas de e-mail, a banco de dados, entre outras características. Graças a essas características, o JEE foi desenvolvido para suportar uma grande quantidade de usuários simultâneos.

STANDALONE: os programas completamente autossuficientes: para seu funcionamento não necessitam de um software auxiliar, como um interpretador, sob o qual terão de ser executados.

11