1. Introdução
O PDF deste documento está disponível |AQUI|.
Os exemplos deste documento estão disponíveis |AQUI|.
1.1. Contenu
Propomos, neste documento, estudar diferentes configurações de operação de um banco de dados. Consideremos a seguinte arquitetura em camadas:
![]() |
O fluxo de execução vai da esquerda para a direita:
- é uma das classes da camada [ui] (Use Interface) que é executada primeiro. Ela instanciará as camadas [metier] e [dao]. Se a camada [ui] for uma interface gráfica, ela aguardará, em seguida, as ações do usuário. Uma ação do usuário pode provocar a execução de métodos em todas as camadas da arquitetura até o banco de dados. O resultado dessas execuções é apresentado ao usuário de uma forma ou de outra;
A função das diferentes camadas poderia ser a seguinte:
- a camada [JDBC] (Java DataBase Connectivity) é uma interface universal de acesso a bancos de dados. Ela sempre apresenta a mesma interface para a camada [DAO]. Se houver uma mudança no SGBD, basta alterar o driver JDBC. A camada [DAO] não sofre alterações, desde que se tenha tomado o cuidado de respeitar uma série de regras. No entanto, é difícil garantir 100% de portabilidade entre SGBD, pois esses frequentemente contêm uma parcela significativa de SQL proprietário que é difícil de ignorar, já que muitas vezes traz ganhos de desempenho. Assim que se utiliza o SQL proprietário, a portabilidade entre o SGBD não é mais possível. Além disso, os SGBD costumam ter políticas diferentes de geração automática de chaves primárias, com palavras reservadas que não são as mesmas em todos os casos. Neste documento, conseguimos, no entanto, portar a arquitetura JDBC estudada para seis SGBD diferentes, aceitando que haja um projeto de configuração para cada um deles;
- a camada [DAO] expõe uma interface de acesso aos dados do banco de dados específico utilizado (a ser diferenciada da interface JDBC, que expõe métodos válidos para qualquer SGBD);
- a camada [métier] implementa as regras de gestão ou regras de negócio da aplicação.
- seus dados de entrada são aqueles provenientes do banco de dados por meio da camada [dao] e/ou aqueles do usuário que lhe são transmitidos pela camada [ui];
- ela gera dados que pode salvar no banco de dados por meio da camada [dao] e/ou devolver à camada [ui] que a consultou, para exibição ao usuário;
- a camada [ui] é a camada que executa as ações do usuário e retorna a ele os resultados dessas ações;
No exemplo acima, a camada [DAO] envia solicitações SQL à camada [JDBC] para execução na camada SGBD. Desde alguns anos (2006), essa arquitetura pode evoluir da seguinte maneira:
![]() |
Agora, é a camada JPA (Java Persistence API) que envia solicitações SQL para a camada JDBC e recebe os resultados. A camada [JPA] apresenta à camada [DAO] operações para persistir, modificar, excluir e obter objetos. A camada [DAO] não emite mais ordens SQL. Essa abordagem é mais portátil, pois as implementações JPA lidam com as diferenças em relação à SGBD, mas é mais lenta do que a tecnologia JDBC. Faremos testes de desempenho para demonstrar isso. A tecnologia JPA formaliza o trabalho realizado pelo framework Hibernate [http://hibernate.org/] anos atrás.
Estudaremos duas camadas [DAO] com uma das duas arquiteturas a seguir:
![]() |
![]() |
Exigiremos que as camadas [DAO1] e [DAO2] implementem a mesma interface [IDAO]. Assim, o teste [JUnitTestsDao] será o mesmo para ambas as configurações e nos permitirá comparar o desempenho. A camada [DAO1] será implementada com o Spring JDBC e a camada [DAO2] com o Spring JPA;
Feito isso, exibiremos a interface [IDAO] na web da seguinte maneira:
![]() |
- em [1], a camada [IDAO] é exposta na web por meio de uma camada web [2] implementada pelo Spring MVC. É de fato a interface [IDAO] que está exposta, e construiremos duas versões do serviço web, dependendo se essa interface for implementada com uma arquitetura [DAO-JDBC] ou [DAO-JPA-JDBC];
- No [B], um cliente remoto utiliza os URL expostos pelo serviço web, que dão acesso aos métodos da camada [IDAO-serveur]. Faremos com que a camada [DAO-Client] [3] implemente a interface [IDAO-serveur] [1]. Isso nos permitirá utilizar o mesmo teste [JUnitTestsDao], já utilizado duas vezes ([4]);
- no [3], a camada [DAO-client] será implementada com o Spring RestTemplate;
Feito isso, protegeremos o acesso ao serviço web:
![]() |
- em [5], a solicitação HTTP do cliente passa por uma camada de autenticação implementada com o Spring Security;
Feito isso, evoluiremos a arquitetura anterior para a seguinte:
![]() |
- em [3], o aplicativo cliente é, ele próprio, um aplicativo web. Este apresentará um formulário [5] que permite consultar os URL do serviço web seguro. Os acessos HTTP ao serviço web seguro serão realizados por meio de uma camada [DAO-client-js] implementada em JavaScript. Essa arquitetura utiliza o que se denomina solicitações entre domínios:
- o serviço web [2] apresenta URL na forma [http://machine1:port1/];
- o aplicativo web cliente [3] é baixado a partir de um URL [http://machine2:port2/]. Se [http://machine2:port2/] não for idêntico a [http://machine1:port1/] (mesma máquina, mesma porta), o navegador do cliente bloqueará as chamadas HTTP da camada [DAO-client-js]. Para resolver esse problema, o serviço web deve permitir solicitações entre domínios. Veremos como;
Os projetos apresentados foram testados com os seis SGBD a seguir:
- MySQL 5 Community Edition;
- SQL Server 2014 Express;
- PostgreSQL 9.4;
- Oracle Express 11g versão 2;
- IBM DB2 Express-C 10.5;
- Firebird 2.5.4;
Para cada um desses SGBD, foram desenvolvidas quatro camadas [DAO] diferentes:
- uma camada implementada com Spring JDBC;
- uma camada implementada com Spring JPA e o provedor JPA Hibernate;
- uma camada implementada com Spring JPA e o provedor JPA EclipseLink;
- uma camada implementada com Spring JPA e o provedor JPA OpenJPA;
Portanto, o que se apresenta aqui é um conjunto de vinte e quatro configurações diferentes. Fizemos um grande esforço de fatoração:
- a maior parte do código é escrita apenas uma vez. Ele se baseia em dois projetos Maven de configuração:
- um configura a camada JDBC;
- o outro configura a camada JPA;
![]() |
![]() |
O projeto de configuração Maven da camada JDBC [1] de um SGBD específico consiste em dois pontos:
- importar o arquivo do driver JDBC;
- definir as credenciais de acesso ao banco de dados utilizado e os diversos comandos SQL que a camada [DAO1] emitirá para o driver JDBC. Embora o SQL seja padronizado, foram encontrados problemas de portabilidade, principalmente devido à presença, nas consultas, de nomes de tabelas/colunas que se revelaram ser palavras-chave proibidas em certos SGBD (tabela ROLES para DB2, coluna PASSWORD para Firebird). Além disso, embora um nome de coluna normalmente não faça distinção entre maiúsculas e minúsculas, encontramos um problema com o PostgreSQL na coluna ID da chave primária das tabelas. Ele exigiu que ela fosse chamada de id, toda em letras minúsculas. Esses são exemplos típicos de problemas inesperados de portabilidade;
Os três projetos Maven de configuração da camada JPA [2] de um SGBD específico também consistem em dois pontos:
- importar o arquivo da implementação JPA;
- configurar a implementação JPA utilizada para o SGBD específico conectado. De fato, é a camada JPA que emite os comandos SQL para a camada JDBC. Para ser eficaz, ela precisa conhecer o SGBD a fim de enviar a ele os comandos SQL que ele reconhecerá. Essas ordens poderão utilizar o SQL, proprietário desse SGBD, bem como as características específicas deste último (tipos de dados, sequências, triggers, procedimentos, geração automática de chaves primárias, etc.);
Assim, temos vinte e quatro projetos (4 configurações x 6 SGBD) de configuração do Maven nos quais se basearão todos os outros projetos de operação do banco de dados. Nos esquemas acima, como as camadas [DAO1] e [DAO2] oferecem a mesma interface, as 24 configurações das duas arquiteturas acima serão testadas com uma única classe de teste [JUnitTestsDao]. Uma vez verificadas essas arquiteturas, não há mais dificuldades:
- o projeto Maven para publicação do banco de dados na web baseia-se nessas duas arquiteturas. Portanto, também há 24 configurações possíveis;
- o projeto Maven para a segurança do acesso ao serviço web baseia-se no projeto anterior e também possui 24 configurações possíveis;
- por fim, o projeto Maven que permite solicitações entre domínios ao serviço web seguro baseia-se no projeto anterior e também possui 24 configurações possíveis;
O estudo foi realizado com o SGBD, o MySQL5 e a implementação JPA do Hibernate. Em seguida, realiza-se a adaptação para as implementações JPA (Eclipselink) e OpenJPA. Em seguida, faz-se a adaptação para os outros bancos de dados (PostgresQL, Oracle; SQL, Server; DB2, Firebird).
Este curso é destinado a iniciantes. A maior parte dos conceitos utilizados é explicada. Não é necessário ter conhecimento de programação de bancos de dados nem de programação web. Por outro lado, são necessários conhecimentos sólidos da linguagem SQL, pois as consultas SQL utilizadas não são explicadas.
Para compreender os exemplos, é necessário ter um conhecimento básico da linguagem Java, que pode ser encontrado em qualquer curso introdutório a essa linguagem. Os dois primeiros capítulos do documento [Introdução à linguagem Java (1998)] são suficientes. Trata-se de um documento antigo (de 1998, revisado em 2002), mas os fundamentos estão lá. Para um curso completo, pode-se ler o extenso livro de Jean-Marie Doudoux, [http://www.jmdoudoux.fr/java].
Este documento não é, de forma alguma, exaustivo. Ele serve apenas para fornecer uma metodologia e códigos que podem ser reutilizados em contextos semelhantes. O documento foi escrito de forma a poder ser lido sem a necessidade de um computador à mão. Por isso, são apresentadas muitas capturas de tela.
Embora não aborde todas as capacidades da linguagem Java nem todos os seus domínios de aplicação, este documento pode ser utilizado como material de aprendizagem da linguagem. Se seguir este documento, mesmo que não na íntegra, o leitor iniciante alcançará um nível “Java avançado”, tanto no uso da linguagem quanto no uso do framework Spring. Ele poderá então continuar sua formação em Java com as seguintes obras:
- [Spring MVC et Thymeleaf par l'exemple] [http://tahe.developpez.com/java/springmvc-thymeleaf], que aprofunda o aprendizado do ecossistema Spring ao apresentar seu ramo de “programação web MVC”;
- [Introdução ao Spring MVC e ao Thymeleaf por meio de exemplos (2015)], que apresenta uma arquitetura web cliente/servidor, na qual o cliente é implementado com o framework [AngularJS] e o servidor com [Spring MVC];
- [Introdução ao Java EE com o IDE NetBeans e o servidor de aplicativos GlassFish (2012)], que abandona o ecossistema Spring em favor de uma arquitetura web baseada em JSF (Java Server Faces) e EJB (Enterprise Java Bean);
- [Introdução à programação de tablets Android com o Android Studio (2016)], que descreve uma arquitetura cliente/servidor, em que o cliente é um tablet Android e o servidor é um serviço web implementado pelo Spring MVC;
1.2. Sources
Este documento tem duas fontes principais:
- [ref1] : [Introdução ao Spring MVC e ao Thymeleaf por meio de exemplos (2015)]. O presente documento retoma, com outro banco de dados, o trabalho realizado e apresentado em [ref1]. Simplesmente, ele o retira do contexto da programação web com Spring (MVC). Foi porque considerei que os códigos e a metodologia utilizados no [ref1] para expor um banco de dados na web eram reutilizáveis que decidi criar um documento separado;
- [ref2] : [Persistência no Java 5 na prática (2007)];
Para se aprofundar no Spring, pode-se utilizar as seguintes referências:
- o documento de referência do framework Spring [http://docs.spring.io/spring/docs/current/spring-framework-reference/pdf/spring-framework-reference.pdf];
- inúmeros tutoriais sobre o Spring podem ser encontrados em URL e [http://spring.io/guides];
- o site de [developpez.com] dedicado ao Spring [http://spring.developpez.com/];
- o tutorial [http://www.tutorialspoint.com/spring/spring_tutorial.pdf];
O leitor com conhecimentos SQL insuficientes poderá adquirir os conceitos básicos com a obra [Introduction au langage SQL avec le SGBD Firebird], disponível em URL [Introdução à linguagem SQL com o SGBD Firebird (2006)].
1.3. As ferramentas utilizadas
Os exemplos a seguir foram testados no seguinte ambiente:
- computador com Windows 8.1 Pro de 64 bits;
- JDK 1.8 (parágrafo 23.1);
- IDE Spring Tool Suite 3.6.3 (parágrafo 1);
- navegador Chrome (outros navegadores não foram utilizados);
- extensão do Chrome [Advanced Rest Client] (parágrafo 1);
- SGBD MySQL 5.6 Community Edition (parágrafo 23.4);
- SGBD SQL Server 2014 Express (parágrafo 23.9);
- SGBD PostgreSQL 9.4 (parágrafo 23.7);
- SGBD Oracle Express 11g versão 2 (parágrafo 23.6);
- SGBD IBM DB2 Express-C 10.5 (parágrafo 23.8);
- SGBD Firebird 2.5.4 (parágrafo 23.10);
- os clientes do EMS Manager de seus seis SGBD (parágrafo 23.5);
Atenção ao JDK 1.8. Um dos casos de estudo utiliza um método do pacote [java.lang] do Java 8.
A maioria dos exemplos são projetos Maven que podem ser abertos tanto no IDE Eclipse quanto no IntellijIDEA e no NetBeans. A seguir, as capturas de tela são do IDE Spring Tool Suite, uma variante do Eclipse.
1.4. Os exemplos
Os exemplos estão disponíveis no URL [http://tahe.developpez.com/java/spring-database] na forma de um arquivo zip para download.
![]() |
- em [1], as pastas dos exemplos;
- em [2], a pasta [spring-core] contém os projetos de aprendizagem do Spring;
- em [3], a pasta [spring-database-config] contém os projetos de configuração JDBC e JPA das seis bases de dados;
![]() |
- em [4], a configuração do SGBD Oracle. Nela há três pastas:
- [databases] contém os scripts SQL para geração dos dois bancos de dados utilizados pelo documento;
- [jdbc-driver] contém o driver JDBC do Oracle, bem como um script para instalá-lo no repositório Maven local;
- [eclipse] contém [5] os quatro projetos de configuração da Oracle:
- [oracle-config-jdbc] configura a camada JDBC de acesso ao SGBD;
- [oracle-config-jpa-hibernate] configura a camada JPA de acesso ao SGBD com o provedor JPA Hibernate;
- [oracle-config-jpa-eclipselink] configura a camada JPA de acesso ao SGBD com o provedor JPA Eclipselink;
- [oracle-config-jpa-openjpa] configura a camada JPA de acesso ao SGBD com o provedor JPA OpenJPA;
- no [6], a pasta [eclipse config / launch configurations] contém as configurações de execução que o usuário poderá importar para o Eclipse para, em seguida, adaptá-las ao seu próprio ambiente;
![]() |
- em [7], a pasta [spring-database-generic] contém todo o código de acesso ao SGBD, comum aos seis SGBD e aos três fornecedores JPA;
- no [8], o [spring-jdbc] contém quatro projetos que apresentam o API, o JDBC e o Spring JDBC;
- em [9], o [spring-jpa / spring-jpa-generic] é o projeto que utiliza uma camada JPA para acessar um banco de dados. Os projetos [generic-create-db*] são projetos JPA que permitem criar os bancos de dados utilizados pela camada JPA;
![]() |
-
no [10], a pasta [spring-webjson] contém os projetos que expõem o banco de dados na web;
- [spring-webjson-server-jdbc-generic] é o serviço web que expõe o banco de dados acessado com o Spring JDBC;
- [spring-webjson-server-jpa-generic] é o serviço web que expõe o banco de dados acessado pelo Spring JPA;
- [spring-webjson-client-generic] é o único cliente que permite acessar os dois serviços web anteriores;
-
no [11], a pasta [spring-security] contém os projetos que expõem o banco de dados na web com acesso seguro;
- [spring-security-server-jdbc-generic] é o serviço web seguro que expõe o banco de dados acessado pelo Spring JDBC;
- [spring-security-server-jpa-generic] é o serviço web seguro que expõe o banco de dados acessado por meio do Spring JPA;
- [spring-security-client-generic] é o único cliente que permite acessar os dois serviços web seguros anteriores;
-
em [12], a pasta [spring-cors] contém os projetos que expõem o banco de dados na web com acesso seguro, permitindo acessos entre domínios, como aqueles provenientes do código JavaScript de um navegador;
- [spring-cors-server-jdbc-generic] é o serviço web seguro que permite acessos entre domínios e que expõe o banco de dados acessado com o Spring JDBC;
- [spring-cors-server-jpa-generic] é o serviço web seguro que permite acessos entre domínios e expõe o banco de dados acessado por meio do Spring JPA;
- [spring-cors-client-generic] é um aplicativo web que permite consultar os dois serviços web anteriores;












