Mapeamento Objeto Relacional Padres de Projetos

Para o desenvolvimento de softwares escalveis e de fcil manuteno devemos considerar o uso de alguns padres de projetos comumente utilizados pelos melhores projetistas de sistemas orientados a objetos. Mas, afinal o que so estes padres? De onde surgiram? Com o passar dos tempos os desenvolvedores de software comearam a perceber que deparavam-se com certos problemas (corriqueiros), e perceberam que a soluo para tais problemas geralmente seguiam a mesma linha de raciocnio. Aps esta descoberta eles tiveram a idia brilhante de documentar todos estes problemas e suas possveis solues, e com isso, surgiram os padres de projetos (design patterns). A principal referncia de tal assunto o livro Design Patterns : Elements of Reusable Object-Oriented Software escrito por: Erich Gamma, Richard Helm, Ralph Johnson e Vliss, popularmente conhecidos como GOF (Gang of Four `Gangue dos Quatro`). Esta publicao contm os 23 principais padres de projetos. Atualmente existem N padres de projetos documentados, porm neste momento, iremos focar apenas nos principais e mais utilizados. (DTO, DAO, Business Service e Business Delegate). A principal regra a se aplicar quando desenvolvemos um sistema de software utilizando a arquitetura orientada a objetos a separao das responsabilidades e criao de objetos altamente coesos de forma a possibilitar a fcil manuteno. Afinal, nenhum desenvolvedor de software em plena conscincia deseja virar noites e noites para dar manuteno em um software e mais importante ainda, no se esquea que a pessoa que manter seu cdigo talvez saiba onde voc mora e com certeza ir perturb-lo incansavelmente, portanto, quando for desenvolver um sistema, faa-o da melhor maneira.

Mos Obra Mapeamento Objeto Relacional

Para o mapeamento objeto relacional, ou seja, a criao de objetos que representaro nossas tabelas da base de dados relacional, temos o padro de projetos denominado DTO (Data Transfer Object) tambm conhecido como POJO. DTO (Data Transfer Object Objeto de transferncia de dados) Descrio: O padro DTO comumente utilizado para reduzir a transferncia de dados pela rede, aumentando ento o desempenho do aplicativo. O objeto DTO o objeto que representa uma tabela da nossa base de dados, logo, ele dever conter os mesmos atributos definidos na base de dados. Principais benefcios: Reduzir trfego de rede. Desacoplar o objeto que contm os dados da lgica de negcios, apresentao e persistncia. Reduz duplicao de cdigo

Vamos criar ento o mapeamento objeto relacional que representar nossas tabelas. Para tal exerccio as tabelas de nossa base de dados foram geradas de acordo com o modelo de classes abaixo:

O diagrama de classes acima foi enxugado para tornar a assimilao do contedo mais simples. Nossa base de dados reflete exatamente o diagrama mostrado acima. Segue abaixo as informaes sobre as tabelas e suas chaves primrias e estrangeiras: Nome Tabela Colunas Chaves Primrias Chaves Estrangeiras

Livro LivroAutor Autor Editora

Isbn, titulo, subttulo e cdEditora Isbn e cdAutor cdAutor e nome cdEditora, nome e email

Isbn Isbn e cdAutor cdAutor cdEditora

cdEditora Isbn e cdAutor No h No h

De acordo com o padro de objetos DTO, devemos representar cada tabela do nosso banco de dados como um objeto Java, o qual dever conter todos os campos da tabela, e dever seguir o padro de nomeao dos JavaBeans. Por padro, costumamos nomear nossos objetos Java com o ttulo da tabela, adicionando apenas o sufixo DTO ao nome do objeto. Sendo assim teremos: LivroDTO, LivroAutorDTO, AutorDTO e EditoraDTO. Segue abaixo os objetos Java criados a partir do nosso modelo de dados:
package br.com.datasun.livraria.dto; public class LivroDTO { private Integer isbn; private String titulo; private String subtitulo; public Integer getIsbn() { return isbn; } public void setIsbn(Integer isbn) { this.isbn = isbn; } public String getSubtitulo() { return subtitulo; } public void setSubtitulo(String subtitulo) { this.subtitulo = subtitulo; } public String getTitulo() { return titulo; } public void setTitulo(String titulo) { this.titulo = titulo; } } package br.com.datasun.livraria.dto; public class AutorDTO { private Integer cdAutor; private String nome; public Integer getCdAutor() { return cdAutor; } public void setCdAutor(Integer cdAutor) { this.cdAutor = cdAutor; } public String getNome() { return nome; } public void setNome(String nome) {

this.nome = nome; } } package br.com.datasun.livraria.dto; public class LivroAutorDTO { private Integer isbn; private Integer cdAutor; public Integer getCdAutor() { return cdAutor; } public void setCdAutor(Integer cdAutor) { this.cdAutor = cdAutor; } public Integer getIsbn() { return isbn; } public void setIsbn(Integer isbn) { this.isbn = isbn; } } package br.com.datasun.livraria.dto; public class EditoraDTO { private Integer cdEditora; private String nome; public Integer getCdEditora() { return cdEditora; } public void setCdEditora(Integer cdEditora) { this.cdEditora = cdEditora; } public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; }

Nota: Os objetos DTO devem conter os mesmos atributos da tabela que ele representa e seus mtodos getters e setters seguindo o padro JavaBeans. Uma vez que temos nosso modelo de dados mapeado e todos nossos objetos Java criados, podemos continuar com a construo de nosso aplicativo. Mas antes vamos conhecer um novo padro: DAO (Data Access Object).

DAO (Data Access Object Objeto de Acesso aos Dados)

Descrio: O padro DAO (Data Access Object) define que toda a lgica de acesso aos dados deve ser separada da lgica de apresentao e lgica do negcio (regras da aplicao). A implementao dos DAOs muito simples, para cada objeto DTO teremos um objeto DAO que ser responsvel por realizar todas as operaes de persistncia deste objeto na base de dados. Logo, nosso objeto dever realizar as operaes comuns com relao persistncia, a saber: Insero Deleo Edio Excluso Busca Principais benefcios: Separa a lgica de persistncia da lgica de negcios. Fcil manuteno. Reduz complexidade do cdigo da regra de negcios. Centraliza todo o acesso aos dados em uma camada separada. Implementao do DAO Da mesma forma como nomeamos os objetos DTO adicionando o sufixo DTO, neste momento iremos criar nossos objetos DAOs e iremos adicionar o sufixo DAO para diferenciarmos nossos objetos de acordo com suas responsabilidades. Seguindo nosso modelo de dados teremos os seguintes objetos: LivroDAO, LivroAutorDAO, AutorDAO e EditoraDAO. Segue abaixo uma implementao tpica de um DAO:
package br.com.datasun.livraria.dao; import import import import br.com.datasun.livraria.dto.LivroDTO; java.sql.*; java.util.ArrayList; java.util.List;

/** * * @author Jose Antonio */ public class LivroDAO { /** Creates a new instance of LivroDAO */ public void insert(LivroDTO livroDTO) throws Exception{ //obtemos uma conexo atravs de uma fbrica de conexes Connection con = ConnectionFactory.getFirebirdConnection(); PreparedStatement psmt = null; try{ StringBuffer sql = new StringBuffer();

sql.append("insert into livro (ISBN, TITULO, SUBTITULO) " ); sql.append("values(?, ?, ?)"); psmt = con.prepareStatement(sql.toString()); psmt.setInt(1, livroDTO.getIsbn()); psmt.setString(2, livroDTO.getTitulo()); psmt.setString(3, livroDTO.getSubtitulo()); psmt.execute(); }finally{ psmt.close(); con.close(); }

} public void update(LivroDTO livroDTO) throws Exception{ //obtemos uma conexo atravs de uma fbrica de conexes Connection con = ConnectionFactory.getFirebirdConnection(); PreparedStatement psmt = null; try{ StringBuffer sql = new StringBuffer(); sql.append("update livro (ISBN, TITULO, SUBTITULO) " ); sql.append("values(?, ?, ?) where ISBN = ?"); psmt = con.prepareStatement(sql.toString()); psmt.setInt(1, livroDTO.getIsbn()); psmt.setString(2, livroDTO.getTitulo()); psmt.setString(3, livroDTO.getSubtitulo()); psmt.setInt(4, livroDTO.getIsbn()); psmt.execute(); }finally{ psmt.close(); con.close(); } } public void delete(LivroDTO livroDTO) throws Exception{ //obtemos uma conexo atravs de uma fbrica de conexes Connection con = ConnectionFactory.getFirebirdConnection(); PreparedStatement psmt = null; try{ StringBuffer sql = new StringBuffer(); sql.append("delete from livro where ISBN = ?"); psmt = con.prepareStatement(sql.toString()); psmt.setInt(1, livroDTO.getIsbn()); psmt.execute(); }finally{ psmt.close(); con.close(); } } public List list()throws Exception{ //obtemos uma conexo atravs de uma fbrica de conexes Connection con = ConnectionFactory.getFirebirdConnection(); ResultSet rs = null; PreparedStatement psmt = null; String sql = "select * from livro"; ArrayList livros = new ArrayList(); //lista que armazenar os livros da consulta

try{ psmt = con.prepareStatement(sql); rs = psmt.executeQuery(); LivroDTO livroDTO = null; while(rs.next()){ livroDTO = new LivroDTO(); livroDTO.setIsbn(rs.getInt("ISBN")); livroDTO.setTitulo(rs.getString("TITULO")); livroDTO.setSubtitulo(rs.getString("SUBTITULO")); livros.add(livroDTO); } }finally{ psmt.close(); rs.close(); con.close(); } return livros; } }

Como podemos observar, os mtodos de nosso objeto LivroDAO recebem como parmetro um objeto LivroDTO, o qual contm os dados do Livro o que dever ser persistido. Ponto importante: Observe que os mtodos do objeto DAO no realizam nenhum tipo de validao dos dados antes de persistir. Como este um objeto que por essncia tem a responsabilidade de persistncia dos dados, no adicionaremos nenhum tipo de validao nele. E agora? E se o usurio no preencher um dos dados do livro? Onde iremos realizar a validao dos dados? Calma, estamos apenas comeando.

Business Service (Regras do servio/negcio) Descrio: O padro Business Service define que toda a lgica das regras de negcio devem ser aplicadas separadamente da lgica de persistncia e apresentao. Principais benefcios: Separa a lgica de negcios da lgica de persistncia. Reduz duplicao de cdigo e facilita a manunteno. Promove uma arquitetura orientada a servios. Centraliza os comportamentos, estados possveis e prov reuso.

aqui que adicinaremos todas nossas validaes! A implementao simples, da mesma forma que criamos os objetos DTO e DAO, criaremos novos objetos para conter somente as regras de negcio da aplicao. Sendo assim, para cada DTO e DAO teremos um objeto Business Service. Por padro, quando criamos estes objetos adicionamos o sufixo BS (de Business Service), sendo assim teremos os seguintes objetos: LivroBS, LivroAutorBS, AutorBS e EditoraBS.

Segue abaixo uma implementao do objeto LivroBS:

package br.com.datasun.livraria.bs; import br.com.datasun.livraria.dao.LivroDAO; import br.com.datasun.livraria.dto.LivroDTO; import java.util.List; public LivroBS() { } public void insert(LivroDTO livroDTO) throws Exception{ if (livroDTO.getIsbn() == null){ throw new Exception("Por favor digite o ISBN do livro!"); } if (livroDTO.getTitulo() == null || livroDTO.getTitulo().equals("")){ throw new Exception("Por favor digite o Ttulo do livro"); } LivroDAO livroDAO = new LivroDAO(); livroDAO.insert(livroDTO); } public void update(LivroDTO livroDTO) throws Exception{ if (livroDTO.getIsbn() == null){ throw new Exception("Por favor digite o ISBN do livro!"); } if (livroDTO.getTitulo() == null || livroDTO.getTitulo().equals("")){ throw new Exception("Por favor digite o Ttulo do livro"); } LivroDAO livroDAO = new LivroDAO(); livroDAO.update(livroDTO); } public void delete(LivroDTO livroDTO) throws Exception{ if (livroDTO.getIsbn() == null){ throw new Exception("Por favor selecione um livro para excluir"); } LivroDAO livroDAO = new LivroDAO(); livroDAO.delete(livroDTO); } public List list()throws Exception{ //no h regras para a listagem de livros LivroDAO livroDAO = new LivroDAO(); return livroDAO.list(); } }

Como podem perceber, o objeto Business Service tem basicamente os mesmos mtodos que o objeto DAO, porm vejam que nosso LivroBS apenas realiza as validaes necessrias e caso suas regras sejam atendidas, ele invoca o objeto DAO para realizar a persistncia do

objeto o qual acabou de validar. Caso as regras no sejam atendidas vejam que nosso cdigo lana uma java.lang.Exception possibilitando ento que outra parte da aplicao capture e trate esta exceo.

Padro Business Delegate Descrio: Os objetos Business Delegate so responsveis delegar tarefas a outros objetos. Exemplo: Solicitar para o objeto BS que implementa a regra de negcios para que realize as validaes necessrias. Principais benefcios: Reduz o acoplamento entre a camada de apresentao e a camada de negcios de forma a facilitara manuteno e permitir o reuso de cdigo. Prov uma interface simplificada de acesso a um servio (Regra de negcio).

Este o objeto responsvel por delegar tarefas aos objetos das outras camadas da aplicao. Um uso comum realizar a invocao da camada de negcios. A implementao do Business Delegate tambm simples , da mesma forma que criamos os objetos DTO e DAO, criaremos novos objetos para conter somente a delegao de tarefas s outras camadas da aplicao. Por padro, quando criamos estes objetos adicionamos o sufixo Delegate (de Business Delegate), sendo assim teremos os seguintes objetos: LivroDelegate, LivroAutorDelegate, AutorDelegate e EditoraDelegate. Eis um exemplo:
package br.com.datasun.livraria.delegate; import br.com.datasun.livraria.bs.LivroBS; import br.com.datasun.livraria.dto.LivroDTO; import java.util.List; /** * * @author Jose Antonio */ public class LivroDelegate { /** Creates a new instance of LivroDelegate */ public LivroDelegate() { } public void insert(LivroDTO livroDTO) throws Exception{ //invoca regra de negcios para insero LivroBS livroBS = new LivroBS(); livroBS.insert(livroDTO); } public void update(LivroDTO livroDTO) throws Exception{ //invoca regra de negcios para atualizao

LivroBS livroBS = new LivroBS(); livroBS.update(livroDTO);

public void delete(LivroDTO livroDTO) throws Exception{ //invoca regra de negcios para deleo LivroBS livroBS = new LivroBS(); livroBS.delete(livroDTO); } public List list()throws Exception{ //invoca regra de negcio para listagem (pesquisa) LivroBS livroBS = new LivroBS(); return livroBS.list(); } }

Nota: Da mesma forma que nosso objeto Business Service, o Delegate dever ter os mesmos mtodos definidos no DAO, porm a implementao destes mtodos devero apenas invocar a regra de negcios como demonstrado no cdigo acima.

Unindo os conhecimentos Entendendo o fluxo dos dados e os padres Segue abaixo o diagrama de sequncia que demonstra a interao dos objetos e como os padres podem trabalhar juntos:

Interao entre a Interface grfica e os Objetos da aplicao O diagrama de interao de objetos acima demonstra uma insero de um livro. Temos a seguinte sequncia de aes:

1. O usurio solicita a insero de um novo livro clicando em um boto salvar em uma GUI. 2. O objeto GUI percebe que o usurio clicou no boto salvar, obtm os valores do formulrio, cria um objeto LivroDTO, configura todas as propriedades, cria um Objeto LivroDelegate e invoca o mtodo insert() passando o livroDTO como argumento. 3. O objeto LivroDelegate cria um objeto do tipo LivroBS e invoca o mtodo insert() passando o objeto livroDTO como argumento para que sejam realizadas as validaes necessrias antes de salvar o objeto na base de dados. 4. O objeto LivroBS realiza as validaes e caso no haja nenhum problema, cria um objeto LivroDAO e invoca o mtodo insert() passando o livroDTO como argumento. 5. Uma vez que todas as validaes j foram aplicadas pelo LivroBS, nosso objeto LivroDAO executar seu mtodo insert(livroDTO) e persistir este objeto na base de dados.

Referncias: http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html