Classes de Entidades Persistentes JDB

Transcrição

1 Classes de Entidades Persistentes JDB Brasil, Natal-RN, 07 de setembro de 2011 Welbson Siqueira Costa Nota de Retificação: em 11/12/2011 a Listagem 3 desse tutorial sofreu uma pequena alteração em seu método main para se prevenir contra drivers JDBC inseguros em relação a threads. É importante salientar que o driver JDBC MySQL não apresentou problemas com o código originalmente escrito na publicação do artigo.

2 Resumo No emprego do paradigma da programação OO (Orientada a Objetos) para concepção de sistemas informatizados, entidades do mundo real são representadas por classes. Em muitos casos, essas classes deverão persistir seus objetos em meios de armazenamento não voláteis. Nesse sentido, tais classes podem ser denominadas de classes de entidades persistentes. Trabalhar com linguagem de programação OO e ter a necessidade de persistir objetos em banco de dados relacional (não orientado a objetos) implica na obrigação de mapear estruturas de classes persistentes para tabelas. Esse mapeamento também interfere na programação do sistema, já que deverão ser codificadas estruturas responsáveis pela garantia da persistência dos objetos das classes em tabelas de banco de dados. Muitos esforços e dificuldades estão relacionados a essa atividade. Por isso, o Framework JDB idealizou o conceito de Classe de Entidade Persistente JDB, que se materializa na forma de uma classe de entidade simples e especialmente codificada, a qual tem a capacidade de persistir objetos de seu próprio tipo em sistemas de bancos de dados relacionais, sem maiores esforços de programação.

3 A abstração é um ato mental largamente utilizado pelos seres humanos na realização de projetos. Não somente bastante utilizado, mas também muito importante, o exercício da abstração consiste em dar atenção àquilo que realmente é significante, desconsiderando, pelo menos em determinado momento, tudo que não está diretamente relacionado ao assunto que se está analisando ou trabalhando. Na análise e modelagem de sistemas de software a importância da abstração também está presente. Nesse sentido, os analistas de sistemas ou desenvolvedores de software voltam suas atenções para entidades do mundo real que estão diretamente relacionadas ao domínio do negócio que se deseja informatizar. No paradigma da programação OO (Orientada a Objetos) tais entidades são as classes. Por exemplo, na análise e modelagem de um sistema de vendas, as entidades: produto, cliente, fornecedor e venda seriam fortes candidatas a se tornarem classes de software. Uma característica muito importante relacionada às classes de software é a necessidade que elas podem ter de persistir seus objetos, ou seja, de armazená-los em meios não voláteis que permitam posterior recuperação, mesmo que o sistema tenha sido desligado. Retornando ao sistema de vendas, seria bastante provável que as possíveis classes citadas anteriormente necessitassem possuir a característica da persistência. Sendo isso confirmado, elas poderão ser denominadas de Classes de Entidades Persistentes. A persistência dos objetos pode ser realizada utilizando-se os mais diversos sistemas de armazenamento disponíveis. No nível tecnológico atual, o meio comumente utilizado são os sistemas de bancos de dados; mais especificamente, os sistemas de bancos de dados relacionais e objetorelacionais 1. Como esses sistemas não representam aspectos do mundo real através de classes, faz-se necessário mapear as estruturas das classes de software para modelos de tabelas (uma atividade denominada de mapeamento objeto-relacional). Tal necessidade ocorre porque os bancos de dados relacionais e objeto-relacionais armazenam seus dados em formatos tabulares. Dessa maneira, cada uma das Classes de Entidades Persistentes poderá ser mapeada para uma tabela do modelo relacional. Em (BEZERRA, 2007) há um 1 Os sistemas de banco de dados objeto-relacionais são sistemas relacionais dotados de algumas características da orientação a objetos.

4 capítulo inteiro que demonstra as várias maneiras de realização do mapeamento objeto-relacional. O mapeamento para tabelas compreende a visão dos dados. Na visão do programa, o sistema deverá lidar com aspectos de codificação específicos relativos à persistência dos dados. Com isso, esforços de programação, que não estão relacionados ao domínio que se está informatizando, deverão ser despendidos para garantia da persistência dos dados. Há muitas estratégias de se lidar com esses aspectos. Seja qual for a estratégia adotada, o desenvolvedor terá, basicamente, duas opções: 1) deverá trabalhar diretamente com a API JDBC; ou, 2) deverá fazer uso de algum subsistema de persistência. Nas seções 1 e 2 são apresentadas duas estratégias de utilização direta da API JDBC; na seção 3 é apresentado o conceito de CEP JDB (Classe de Entidade Persistente JDB) para garantia da persistência de dados de forma mais produtiva; na seção 4 é demonstrado como trabalhar com CEP JDB. 1. Classe de Entidade com Métodos para Persistência Nessa estratégia, o programador dota cada classe de entidade com métodos responsáveis pela persistência de seus próprios objetos. Por exemplo, considerando a classe Produto (Figura 1). É possível observar que ela possui os métodos inserir, salvar, excluir e consultar, os quais servem apenas para persistência dos objetos da própria classe. O código responsável pela implementação, no interior de cada método, lida diretamente com a API JDBC. É nesse ponto onde os desenvolvedores têm que voltar suas atenções para aspectos que não fazem parte do domínio do negócio que estão informatizando. É também aqui o local onde se desperdiça recursos (tempo, dinheiro, força de trabalho, entre outros).

5 Figura 1 Classe de Entidade Persistente Produto. Além do desperdício de recursos e do desvio das atenções dos reais objetivos, cada classe escrita dessa maneira torna-se uma classe pouco coesa, ou seja, ela se responsabiliza por operações diversas. Levando em consideração que o software a ser desenvolvido o poderá possuir dezenas de classes de entidades persistentes, as dificuldades identificadas se multiplicarão. Fator ainda mais importante está relacionado à manutenabilidade, a qual também se apresentará comprometida em virtude do aumento da complexidade de cada classe envolvida no sistema. Para se ter uma pequena idéia das dificuldades, a simples migração para sistema de banco de dados diferente do originalmente utilizado poderá requerer adequações em muitos dos métodos de persistência stência de cada uma das classes, já que o código responsável por persistir os dados está espalhado pelas várias classes do software. 2. Padrão DAO (Data Access Object) O padrão DAO acarreta maior complexidade ao software desenvolvido, no entanto dota o sistema de características que facilitam manutenções futuras. Ele garante que cada classe envolvida seja responsável por operações que estão relacionadas apenas à sua atividade principal. Por exemplo, observando a Figura 2, é possível perceber que a classe Produto só possui os métodos

6 get e set para manipulação de seus atributos, ordem, nome, e valor. Dessa maneira diz-se que essa classe de entidade é altamente coesa, pois se responsabiliza apenas por sua atividade fim, que é manter uma representação de objetos do tipo Produto. As operações de persistência ficam separadas na classe DAOProduto,, a qual mantém um relacionamento de dependência com a classe de entidade persistente Produto.. O relacionamento de dependência ocorre porque DAOProduto tem métodos que recebem objetos do tipo Produto como parâmetro ou retornam objetos Produto.. Não é difícil entender que DAOProduto precisa conhecer Produto para persistir seus objetos. A interface IDAOProduto serve apenas para garantir um acoplamento abstrato entre a Aplicação e a classe DAOProduto. Com isso, a Aplicação lida apenas com os métodos da interface, sem necessidade de conhecer os detalhes da classe DAOProduto. Em (BEZERRA, 2007) é possível obter maiores explicações sobre acoplamento abstrato. Para saber mais sobre o padrão DAO veja (ORACLE, 2010). Figura 2 Padrão DAO. Conforme já dito, esse padrão tem a desvantagem de aumentar a complexidade do sistema de software a ser desenvolvido, contudo aumenta sua flexibilidade e manutenabilidade, pois o código responsável pela

7 persistência concentra-se nas classes DAO. Ele também é bastante utilizado quando um sistema de computador necessita armazenar seus dados em diferentes sistemas de persistência 2. Essa característica é denominada de interoperabilidade. Desse modo, cada classe de entidade persistente deverá está associada a uma classe DAO específica para determinado sistema de persistência. Assim, a classe DAO será responsável por persistir dados da classe de entidade em sistema de persistência específico. 3. Classe de Entidade Persistente JDB O JDB traz uma grande facilidade para se trabalhar com classes de entidades persistentes e bancos de dados relacionais. Uma CEP JDB (Classe de Entidade Persistente JDB) é definida como uma classe de entidade que corresponderá a uma tabela do modelo relacional. Ela deverá herdar da classe AbstractEntity, reescrever um de seu métodos construtores e ter o mesmo nome da tabela do banco de dados que representa. A Figura 3 apresenta a hierarquia de herança das CEP JDB. É possível observar que a classe AbstractEntity herda de JDBQuery, portanto ela é uma JDBQuery; sendo assim, possui capacidade de lidar com a persistência de dados em sistemas relacionais e objeto-relacionais. AbstractEntity possui três construtores, um método get e outro set: 1) AbstractEntity(): é o construtor padrão que configura a consulta SQL da superclasse JDBQuery com valor padrão. A consulta padrão retorna todos os registros da tabela de mesmo nome que a classe filha de AbstractEntity; 2) AbstractEntity(jdbconnection : JDBConnection): também configura a consulta SQL do JDBQuery com o valor padrão e ainda permite que seja definido o JDBConnection para conexão com o banco de dados; 2 Exemplos de sistemas de persistência são: sistemas de bancos de dados relacionais, objeto-relacionais ou orientados a objetos; arquivos texto; arquivos XML; entre outros.

8 3) AbstractEntity(jdbconnection : JDBConnection, SQL : String): permite que o programador defina o JDBConnection e a consulta SQL; 4) getfield(fieldname : String) : Object: retorna o valor armazenado na coluna, especificada no parâmetro fieldname, da tabela definida na consulta SQL. Retorna o valor como um Object de Java, portanto o programador deverá fazer uma coerção desse valor recebido para o tipo apropriado; 5) setfield(fieldname : String, value : Object): configura a coluna, especificada no parâmetro fieldname, da tabela definida na consulta SQL, com o valor especificado no parâmetro value. Figura 3 Estrutura de herança das CEP JDB. Uma vez que tenha herdado da classe AbstractEntity e reescrito pelo menos um de seus construtores, a classe de entidade deverá apenas implementar os métodos get e set para cada coluna da tabela que ela representa. A próxima seção demonstra como fazer isso. 4. Exemplo de Aplicação de CEP JDB Nessa seção é implementada uma simples aplicação para demonstração do uso de CEP JDB. O banco de dados do programa é armazenado no SGBD

9 (Sistema Gerenciados de Bancos de Dados) 3 MySQL (MYSQL, 2010). A compilação 4 e execução do programa ocorrem no SO (Sistema Operacional) Windows 7. O programa desenvolvido será armazenado no seguinte diretório: C:\cep_produto\ No interior desse diretório o leitor deverá criar um subdiretório denominado de lib, o qual deverá conter o driver JDBC de conexão com o banco de dados MySQL, disponível no arquivo mysql-connector-java bin.jar (caso deseje, o leitor poderá baixar um driver JDBC MySQL mais atual). O diretório lib também deverá conter o Framework JDB, disponível no arquivo JDB.jar (Veja a Figura 7). Figura 4 Classe de Entidade Persistente Produto. Considerando que a classe de entidade persistente Produto (Figura 4) tem a necessidade de armazenar seus objetos em um sistema de banco de dados relacional; ela deverá ser mapeada para uma tabela desse banco de dados. A Figura 5 apresenta o desenho da tabela produto. A Listagem 1 mostra o código SQL necessário para criar o banco de dados dbproduto e a tabela produto no SGBD MySQL. 3 Deve-se entender SGBD como um sinônimo para Sistema de Banco de Dados. 4 Compilar um programa Java consiste em gerar seus bytecodes.

10 Figura 5 Tabela produto correspondente a classe Produto. 5 1 CREATE DATABASE dbproduto; 2 3 CREATE TABLE dbproduto.produto ( 4 id int(11) NOT NULL AUTO_INCREMENT, 5 ordem int(11) NOT NULL, 6 nome varchar(40) NOT NULL, 7 valor double NOT NULL, 8 PRIMARY KEY (id) 9 ); Listagem 1 Código SQL para criação do banco de dados. Uma vez que a tabela produto tenha sido criada, faz-se necessário codificar a CEP JDB Produto, conforme código da Listagem 2. Essa classe deverá ser escrita em um arquivo texto, sem formatação, denominado de Produto.java e, conforme demonstrado na Figura 7, deverá ser armazenada no seguinte caminho de diretório: C:\cep_produto\entity\Produto.java Na Listagem 2 observa-se que apenas um construtor de AbstractEntity foi reescrito e que há métodos get e set para cada um dos atributos da classe Produto (Figura 4) ou colunas da tabela produto (Figura 5). Percebe-se que não é necessário definir os atributos. Os métodos get fazem uso do método getfield da superclasse AbstractEntity, o qual retorna um Object contendo o valor desejado. Por isso há a coerção para o tipo correspondente, por exemplo, na linha 13, return (Integer) super.getfield("id"); 5 Figura gerada através do programa MySQL Workbench obtido em (MYSQL, 2010).

11 há uma coerção para o tipo Integer, já que a coluna id da tabela produto é do tipo Integer. Os métodos set fazem o uso do método setfield herdado de AbstractEntity, o qual deve receber um objeto de tipo correspondente à coluna que se deseja configurar. Como pode ser visto na linha 17, super.setfield("id", id); o primeiro parâmetro, id, refere-se à coluna id da tabela produto, o segundo parâmetro é o valor que será configurado em id, o qual deverá ser do tipo Integer. 1 package entity; 2 3 import lib.jdb.connection.jdbconnection; 4 import lib.jdb.persistence.abstractentity; 5 6 public class Produto extends AbstractEntity 7 { 8 public Produto(JDBConnection jdbconnection, String SQL){ 9 super(jdbconnection, SQL); 10 } public Integer getid() { 13 return (Integer) super.getfield("id"); 14 } public void setid(integer id) { 17 super.setfield("id", id); 18 } public Integer getordem() { 21 return (Integer) super.getfield("ordem"); 22 } public void setordem(integer ordem) { 25 super.setfield("ordem", ordem); 26 } public String getnome() { 29 return (String) super.getfield("nome"); 30 } public void setnome(string nome) { 33 super.setfield("nome", nome); 34 } public Double getvalor() { 37 return (Double) super.getfield("valor"); 38 } 39

12 40 public void setvalor(double valor) { 41 super.setfield("valor", valor); 42 } 43 } Listagem 2 - Codificação da CEP JDB Produto. A Listagem 3 apresenta o código da classe TesteProduto.java, qual corresponde ao programa que faz uso da CEP JDB Produto. Essa classe deverá ser escrita em um arquivo texto, sem formatação e, conforme demonstrado na Figura 7, deverá ser armazenada no seguinte caminho de diretório: C:\cep_produto\gui\TesteProduto.java O programa TesteProduto é bastante simples, mas demonstra operações de inserção, alteração, exclusão e consulta realizadas através de uma CEP JDB. É facilmente perceptível que o código responsável por realizar tais operações torna-se muito mais agradável no contexto da programação OO, pois o programador passa a interagir com um objeto coleção e não com tabelas de um banco de dados relacional. É isso que uma CEP JDB proporciona, ela é uma coleção de objetos do seu tipo, que estão sendo armazenados em um SGBD relacional sem maiores esforços de programação. 1 package gui; 2 3 import lib.jdb.connection.jdbconnection; 4 import entity.produto; 5 6 public class TesteProduto { 7 8 private JDBConnection jdbconnection = null; 9 private Produto produto = null; 10 private Integer lastordem = 0; 11 private Integer ordem; 12 private String nome; 13 private Double valor; public TesteProduto() { // Configura a conexao com o banco de dados. 18 jdbconnection = new JDBConnection(); 19 jdbconnection.setdriver("com.mysql.jdbc.driver"); 20 jdbconnection.seturl("jdbc:mysql:// /dbproduto"); 21 jdbconnection.setusername("root"); 22 jdbconnection.setpassword("rootjdb"); 23 jdbconnection.connectdb(); 24

13 25 // Cria o objeto da Classe de Entidade Persistente produto. 26 produto = new Produto(jDBConnection, 27 "SELECT * FROM produto ORDER BY ordem"); 28 produto.setvisiblefields("nome ordem valor"); // Configura a lastordem. 31 setlastordem(); System.out.println("\n\nInsere dois registros:\n"); 34 add(); 35 list(); System.out.println("\n\nAltera o ultimo registro:\n"); 38 edit(); 39 list(); System.out.println("\n\nExclui o penultimo registro:\n"); 42 delete(); 43 list(); 44 } private void setlastordem() { 47 if (produto.getqueryquantity() > 0) { 48 produto.last(); 49 lastordem = produto.getordem(); 50 } 51 } private void add() { 54 // Define os valores. 55 ordem = lastordem + 1; 56 nome = "Nome " + ordem.tostring(); 57 valor = ordem; 58 // Configura os valores e salva a insercao. 59 produto.insert(); 60 produto.setordem(ordem); 61 produto.setnome(nome); 62 produto.setvalor(valor); 63 produto.save(); // Define os valores. 66 ordem++; 67 nome = "Nome " + ordem.tostring(); 68 valor = ordem; 69 // Configura os valores e salva a insercao. 70 produto.insert(); 71 produto.setordem(ordem); 72 produto.setnome(nome); 73 produto.setvalor(valor); 74 produto.save(); 75 } private void edit() { 78 // Define os valores. 79 nome = produto.getnome().touppercase(); 80 valor = produto.getvalor() ; 81 // Configura os valores e salva a edicao. 82 produto.edit();

14 83 produto.setnome(nome); 84 produto.setvalor(valor); 85 produto.save(); 86 } private void delete() { 89 int penultimo = produto.getqueryquantity() - 1; 90 produto.absoluteposition(penultimo); 91 produto.delete(); 92 } private void list() { 95 System.out.println(produto.getRowsVisible().toString()); 96 } public static void main(string[] args) { 99 java.awt.eventqueue.invokelater(new Runnable() { 100 public void run() { 101 new TesteProduto(); 102 } 103 }); 104 } } Listagem 3 Código fonte da classe TesteProduto. Para gerar os bytecodes do programa é necessário acessar o interpretador de comandos do SO, seguir até o interior do diretório raiz do programa e entrar com o comando apresentado na Figura 6. Figura 6 Gerando os bytecodes do programa. Ao executar o comando a estrutura de diretórios e arquivos do seu programa conterá os arquivos.class, os quais contém os bytecodes (Figura 7).

15 Figura 7 Organização do sistema após geração de bytecodes. Após gerar os bytecodes é possível rodar o software. Então, ainda no interpretador de comandos é necessário entrar com o comando exibido no topo da Figura 8. Após a execução, o programa realizará a inserção de dois produtos, a alteração do último recentemente inserido e a exclusão do penúltimo recentemente inserido. Dessa maneira, após três execuções tem-se o resultado apresentado na última linha da Figura 9. Figura 8 Primeira execução do programa.

16 Figura 9 Terceira execução do programa. 5. Considerações Finais CEP JDB podem funcionar como componentes JavaBeans. Para isso, elas deverão reescrever o construtor padrão de AbstractEntity. Veja o tutorial Tratando Classes de Entidades Persistentes como Componentes em (SIQUEIRA, 2011). Também é importante lembrar que uma CEP JDB é uma JDBQuery, portanto, poderá ser utilizada para programação baseada em componentes no IDE Netbeans como demonstrado nos tutoriais disponíveis no site oficial do projeto É necessário saber que os métodos getfield e setfield de AbstractEntity retornam e configuram, respectivamente, valores de colunas das tabelas que uma determinada CEP JDB representa, levando em consideração o tipo de dado determinado pelo driver JDBC. Dessa maneira, o método getfield( id ) retornará um Integer no interior de um Object Java, caso o driver JDBC informe ao JDB que o tipo de dado da coluna id é Integer. Da mesma maneira o método setfield( id, id) deverá receber um Integer em seu segundo parâmetro para que a coluna definida no primeiro parâmetro possa ser configurada. É possível que drivers JDB fornecidos por determinados fabricantes de SGBD apresentem erros no mapeamento de seus tipos de dados para os tipos Java. Isso poderá causar problemas na utilização das CEP JDB. Entretanto, o Framework JDB fornece uma maneira para que o programador possa contornar essa deficiência e

17 definir o correto tipo de dado para cada coluna trazida em uma consulta SQL. Para saber mais sobre essa configuração o leitor poderá estudar a documentação JavaDoc dos métodos: lib.jdb.jdbquery.jdbquery.setcustomfieldstypes (java.lang.string customfieldstypes); lib.jdb.jdbquery.jdbquery.getcustomfieldstypes(); Para conferir qual o tipo de dado que o JDBQuery está usando para cada coluna trazida na consulta SQL, pode-se utilizar os métodos: lib.jdb.jdbquery.jdbquery.getfieldstypes(); lib.jdb.jdbquery.jdbquery.getfieldstypesnames(); lib.jdb.jdbquery.jdbquery.getfieldtype(int indexfield) lib.jdb.jdbquery.jdbquery.getfieldtype( java.lang.string fieldname); lib.jdb.jdbquery.jdbquery.getfieldtypename( int indexfield); lib.jdb.jdbquery.jdbquery.getfieldtypename( java.lang.string fieldname); 6. Referências BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, MYSQL. MySQL database. MySQL Downloads, Disponivel em: < Acesso em: 10 dez ORACLE. Data Access Object. Java 2 EE, Disponivel em: < Acesso em: 8 out SIQUEIRA, W. Tratando Classes de Entidades Persistentes como componentes. JDB Framework, Disponivel em: < Acesso em: 6 set

18 SIQUEIRA, W. Tutoriais JDB. JDB Framework, Disponivel em: < Acesso em: 6 set