Hibernate Schema Diferente via Java Project

olá Pessoal,

Este post é levemente diferente do que vimos no Mapeando schemas diferentes com o Hibernate. Lá tivemos que criar um bean para representar à tabela, neste aqui vamos usar um mapeamento para tabela já existente, assim evitamos de ter dois beans para uma mesma tabela.

Lets go…

Contexto

No post Mapeando schemas diferentes com o Hibernate assumimos que não existia nenhuma projeto Java que usasse o schema ereaders. Mas, no contexto de hoje vamos supor que tenha um outro projeto que use e já tenha os devidos mapeamentos para a tabela ereaders.usuario e não queremos ter que criar um novo bean em nosso projeto só para ler esse schema, pensamos em aproveitar o mapeamento já feito e usá-lo. Isso nos ajuda até em não ter que ficar atualizando cada bean, caso algum atributo da tabela venha sofrer alteração. Então temos os seguintes projetos Java:

O projeto sem enumeração é o que tem o mapeamento usando annotations para tabela que está em ereaders. Como usar esse bean em outro projeto java?

Muito simples, basta adicionarmos ao projeto HibernateSchema2 uma dependencia com o projeto HibernateSchema. Assim, podemos acessar as classes disponiveis naquele projeto. Para fazer isso, clique com o botão direito do projeto >> build path >> configure build path e adicione o projeto HibernateSchema, conforme a imagem a seguir:

No arquibo hibernate.cfg.xml informamos a classe nova que o projeto deve reconhecer via Hibernate:

< mapping class=“br.com.camilolopes.bean.Usuarios”/ >

Testando

Faremos algo semelhante ao que vimos no outro post, vamos ler dados da tabela e imprimir o valor em seguida, porém vamos usar Criteria API:

publicclass UserDAO extends DAO {

publicList getListUsers(){

begin();

Criteria criteria = getSession().createCriteria(Usuarios.class);

return criteria.list();

}

}

Na classe main, adicionamos o codigo:

publicstaticvoid main(String[] args) {

UserDAO userDAO = new UserDAO();

List<Usuarios> listUsers = userDAO.getListUsers();

for (Usuarios usuarios : listUsers) {

System.out.println(usuarios.getEmail()); } }

O resultado:

Nada de novo, o mesmo resultado que tivemos no outro post. Mas, qual a diferença? Veremos isso com base no que pode ser “problema” em alguns projetos.

Problema

  • um dos problemas é ter dependência com outro projeto, ou seja, se o outro não buildar/compilar o seu ficará preso. E isso em alguns cenários pode ser ruim. Depende da relação entre os projetos.

Vantagem

  • você não precisa ter mais dois beans para mesma tabela, então tudo é focado apenas no bean que já está no outro projeto, caso esta sofra alterações não preciso mudar no projeto HibernateSchema2. E evita essas duplicações de beans.

Qual usar?

Como falei, não há segredo, e sim necessidade, o que seu projeto importa mais? O que for mais importante é o que vai precisar.

Vou ficando por aqui espero que tenham gostado do post.

Abracos, see ya! 

Mapeando Schemas diferentes Hibernate

olá Pessoal,

O post de hj veremos como ler uma tabela que está em um schema diferente do default do seu projeto usando o Hibernate. Será um post curto e bem prático.
Lets go…

Contexto

A situação aqui é muito simples. Precisamos ler uma tabela que está em outro schema do banco de dados via Hibernate. O que fazer?

Primeiro
Terá que ter o modelo da tabela e criar um bean no seu projeto Java e fazer os devidos mapeamento com base no modelo algo como:

@Entity
@Table(name=”Usuario”, schema=”ereaders”)
public class Usuarios {
@Id
@GeneratedValue
private int id;
@Column
private String nome;
@Column
private String email;
//getters/setters omitidos

Observe onde temos o pulo do gato, no atributo schema da anotação @Table onde informo qual schema usar. Por default é usado o que foi definido no arquivo hibernate.cfg.xml. Por falar nele precisamos atualizar com o novo bean ao <mapping/> :class=”br.com.camilolopes.bean.Usuarios”

note: assuma que seu hibernate.cfg.xml está apontando para um BD diferente. Alguma coisa como:
<property name=”hibernate.connection.url”>jdbc:mysql://localhost/auge</property>

Testando
Podemos checkar se de fato o conteúdo da tabela Usuario do schema ereaders, é o que está sendo lido, para isso, temos o seguinte dado na tabela Usuario:

 

Aqui nos temos os Bds:

DAO
Vou assumir que você já tem seu DAO implementado e inicializando as sessões corretamente, caso tenha dúvida verifique os posts sobre o assunto na categoria de Hibernate do blog. Criei uma classe que vai usar HQL para fazer um select na tabela e em seguida imprimir:

public class UsuariosDAO extends DAO {   
    public List getListUsuarios(){
        begin();
        Session session = getSession();
        String hql = “select us.email from Usuarios us”;
        Query query = session.createQuery(hql);
        List list = query.list();
            return list;
    }
}

Na classe main,vamos colocar isso só para ver o resultado:
public static void main(String[] args) {
        UsuariosDAO usuariosDAO = new UsuariosDAO();
                List<String> listUsuarios = usuariosDAO.getListUsuarios();
        for (String usuarios : listUsuarios) {
            System.out.println(usuarios);
        }
    }

Resultado

 

Enfim, temos dados de uma tabela em outro schema. A linha acima de camilo@ é que habilitei o sql_show no arquivo de configuração do hibernate.cfg.xml.

Problema
Como tudo não são flores, um problema aqui é que você não pode esquecer que o usuario informado no hibernate.cfg.xml deve ter permissão ao menos de leitura das tabelas no outro esquema. Do contrário verá exceções na tela com a mensagem permission denied. Se o usuário for diferente terá que criar uma session com o user que tem permissão.

Vou ficando por aqui, espero que tenham gostado do post. Muito simples não é?
Abraços, see ya!!

Criando Mocks com Mockito

olá Pessoal,

No post de hoje vamos ver como usar o API Mockito para criação de objetos mocks. No ultimo post vimos o que são mocks, mas eu já tinha falado rapidamente do Mockito. Usarei o mesmo exemplo visto no post passado, porém agora teremos mocks in action.

Lets go…

Usando JUnit com o Mockito

Para não ter que repetir o código anterior, neste post adicionei apenas a classe que tem o unit test. Então, vou considerar que você viu o nosso post sobre Mocks.

Agora precisamos testar a classe AlugaCarro e ver se de fato ela está retornando um objeto que possui as informações que esperamos que tenha.

Classe de teste

publicclass CarroAlugadoTest {

@Mock

private AlugaCarro alugaCarro;//my interface

public CarroAlugadoTest() {

alugaCarro = Mockito.mock(Cliente.class);

}

@Test

publicvoid alugaCarroParaCliente(){

//o caraquerecebeoscarrosalugados

CarroAlugado car = new CarroAlugado(alugaCarro);

String resultadoEsperado = “Camilo Golf”;

/*

* aqui o clientecamiloestáreservando o carro golf

*/

Mockito.when(alugaCarro.getNomeCliente()).thenReturn(“Camilo “);

Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Golf”);

String verdadeiroResultado = car.getAlugaCarro().getNomeCliente() + car.getAlugaCarro().getModeloCarro();

Mockito.verify(alugaCarro).getNomeCliente();

assertEquals(resultadoEsperado,verdadeiroResultado);

}

Explicado partes importantes do código

Passo 1

Precisamos fazer a mock,ou seja, “mockar” uma classe/interface, há várias formas de fazer isso, usaremos o modo mais simples, que é usar annotations @Mock na variável que vai ser o objeto e “instanciar” ela no construtor, pois quando a classe for carregada a variável será “mockada”.

@Mock

private AlugaCarro alugaCarro;

public CarroAlugadoTest() {

alugaCarro = Mockito.mock(Cliente.class);

}

Passo 2

Criamos um teste onde vamos verificar se um carro foi alugado para o cliente.

Primeiro passo foi passar o objeto “mockado” que representa “o cliente” para a classe CarroAlugado, pois é isso que ela espera receber, um objeto que alugou um carro.

  1. CarroAlugado car = new CarroAlugado(alugaCarro);

Em seguida vamos configurar os valores para o método que recebe o nome do cliente e o que recebe o nome do carro alugado. Porém, aqui usaremos API Mockito. Essa linha de código será executada quando o método for invocado.

  1. Mockito.when(alugaCarro.getNomeCliente()).thenReturn(“Camilo “);
  2. Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Golf”);

A leitura poderia ser algo do tipo: “quando o metodo getNomeCliente() for chamado, então configure o valor dele para “camilo”.

Na linha seguinte, observe que chamamos os métodos, que acreditamos estarem com um valor. E ai o mockito entra in action, quando um objeto, chama um daqueles métodos, ele configura os valores que estão no thenReturn().

  1. String verdadeiroResultado = car.getAlugaCarro().getNomeCliente() + car.getAlugaCarro().getModeloCarro();
  2. Mockito.verify(alugaCarro).getNomeCliente();

O método verify() apenas verifica se o método foi chamado, no API Docs do Mockito, há outras pessoas de verificação, como por exemplo:

  • verificar se o metodo getNomeCliente() foi chamado pelo menos 1 vez, ou mais vezes;
  • verificar se nunca foi chamado.

O assertEquals é somente para verificar se estamos recebendo o valor esperado.

Outro teste que foi implementado:

@Test

publicvoid verificaSeUmMetodoNuncaFoiExecutado(){

CarroAlugado carroAlugado = new CarroAlugado(alugaCarro);

Mockito.when(alugaCarro.getModeloCarro()).thenReturn(“Civic”);

//verificase o metodo getNomeCliente() nuncafoiexecutado

String modeloCarro = carroAlugado.getAlugaCarro().getModeloCarro();

Mockito.verify(alugaCarro, Mockito.never()).getNomeCliente();

}

Um video

Um video do Vinicius mostra a diferença entre mock & Stubs que achei muito bom.

http://viniciusquaiato.com/blog/diferenca-entre-mocks-e-stubs/

Conclusão

Uma outra dica é você gastar um bom tempo ali na documentação do Mockito, ela é bastante rica e de fácil leitura. A API não é tão grande e muito menos complexa, basta um pouco de pratica e sabendo como usar cada recurso, tá feito.

Vou ficando por aqui e espero que tenham gostado do post.

Abracos, see ya!

Mock com Mockito

Olá Pessoal,

Hoje vou apresentar o Mockito que é uma API de Mock, que tem ganhando espaço a cada dia. No post, vou falar pra que serve aos Mocks, o que evitamos e farei “reutilização da informação” sobre o que são mocks.  E para deixar tudo claro nada melhor que um exemplo feijão com arroz,  para que você possa entender como usar.  No próximo post veremos na pratica a criação de Mocks com Mockito.

Lets go…

Pra que serve o mockito?

Mockito  é uma API desenvolvida pela Google, com o objetivo de simular um objeto real para uma classe especifica. Isso pode ajudar nos testes de unidade quando precisamos verificar  a comunicação entre os objetos.

Por que usar Mock?

Usamos Mock quando temos classes que possuem dependencias, porém queremos testar apenas se uma classe está  retornando o que estamos esperando.

E o que evitamos usando mock?

Evitamos de ter que criar objetos para todas as dependencias de uma classe. Ou seja, com o mockito vamos “enganar” a execução do programa, dizendo pra ele que o objeto a ser passado é de fato o objeto que ele espera.

Na pratica

Antes de apresentar os códigos, vamos precisar pegar o conceito do “negócio” e saber como os códigos trabalham.

O cenário é o seguinte:

  • Class Cliente : um cliente ele possui alguns atributos como id, nome.
  • Classe CarroAlugado: esta classe tem como objetivo de informar/representar qual carro está alugado e para quem está alugado (cliente).  Então aqui já podemos ver que essa classe depende de um objeto da classe Cliente. Pois, um objeto da classe cliente que terá essas informações.
  • Interface AlugarCarro: temos uma interface que aluga carro, como o procedimento de alugar carro é sempre o mesmo, de ter o nome de quem está alugando  + o carro que foi alugado. Então se um cliente quiser alugar um carro terá que assinar um contrato com essa interface e informar pra ela o nome dele e o carro que deseja alugar.

E onde Mocks entram nessa história?

Mocs vão  entrar no momento que vamos simular que um cliente  c “Zezinhi” alugou um carro “Ferrari” e vamos ver se de fato  a classe tem essa reserva feita.

Os códigos a seguir:

public interface AlugaCarro {

      public void setNomeCliente(String nomeCliente);

      public void setModeloCarro(String nomeCarro);

      public String getNomeCliente();

      public String getModeloCarro();

}

Classe Cliente implementando a Interface, pois um cliente está querendo alugar um carro.

public class Cliente implements AlugaCarro {

      private String nomeCliente;

      private String modeloCarro;

      @Override

      public void setNomeCliente(String nomeCliente) {

            this.nomeCliente = nomeCliente;

      }

      @Override

      public void setModeloCarro(String nomeCarro) {

            modeloCarro = nomeCarro;

      }

      @Override

      public String getNomeCliente() {

            // TODO Auto-generated method stub

            return nomeCliente;

      }

      @Override

      public String getModeloCarro() {

            // TODO Auto-generated method stub

            return modeloCarro;

      }

}

A classe CarroAlugado  quer receber um objeto que foi instanciado contendo nome do cliente e o nome do carro alugado, e retornar esse objeto. Que nada mais é o Cliente que alugou o carro. Lembre-se o Cliente implements AlugaCarro, então temos o relacionamento HAS-A.  

public class CarroAlugado {        

      private AlugaCarro alugaCarro;

     public CarroAlugado(AlugaCarro alugaCarro) {

            this.alugaCarro = alugaCarro;

      }

      public AlugaCarro getAlugaCarro() {

            return alugaCarro;      }

      public void setAlugaCarro(AlugaCarro alugaCarro) {

            this.alugaCarro = alugaCarro;

      }    

}

Na edição 49 da revista MundoJ tem um artigo que escrevi junto com o Alexandre Gazola sobre o assunto. E lá detalhamos mais, eu sou suspeito de recomendar essa edição :).
vou ficando por aqui, espero que tenham gostado do post.

abracos, see ya!!

Blog Retrospectiva 2011

 

opa! Pessoal,

Um pouco sumido depois de um pequeno recesso e em ritmo de confratenizações, mas agora de volta a vida real :). Nesse primeiro post do ano quero fazer uma restropectiva do ano que se passou, algo que sempre faço aqui no blog. Sendo assim, vou falar um pouco como foi o ano de 2011 para o Camilo, blog etc. E ver o que temos para 2012.

Meu 2011

Foi um dos anos mais turbulentos que passei até hoje, pelo menos não tive trajédias,mas é como pegar um voo e ficar toda viagem em turbulência. Mas, no final aprendi muito (com “dor”). Para quem acompanha o blog uma das grandes mudanças que fiz foi mudar de estado saindo de SP e vindo para RS. E como isso não estava nos meus planos o processo de adaptação  ao novo ambiente, processo de mudança, empresa eprojeto não é algo que acontece rapidamente da noite/dia. Leva tempo e nem sempre acontece como imaginamos. Sempre há aquelas surpresas que muda toda historia e nos faz mudar o contexto e às vezes até o rumo.

Este ano eu bloguei menos, infelizmente meu tempo diminuiu e novos problemas começaram a surgir e tive que priorizar a resolução, portanto o tempo para blogar era quase zero.

Com bastante dificuldade conseguir publicar meu livro JEE com frameworks que começei escrever em 2009. Foi um dos objetivos que conseguir atingir. Publiquei um artigo na MundoJ junto com outro colega(Alexandre Gazola) Pois, era algo que sempre quis publicar um artigo com outro profissional, pois o aprendizado é muito maior com relação quando escrevemos sozinho.

E uma das coisas mais importante que considerei foi ter vindo trabalhar na HP e poder conhecer melhor como funciona as coisas nos bastidores principalmente à nível de R&D. Algo que não tinha experiência e foi bastante desafiador e que certamente teve uma grande contribuição dentro da minha carreira.

Mas, não atingir nem 50% das minhas metas profissionais/pessoais isso foi a frustação de 2011.Que pela primeira vez saio com esse resultado tão triste. Os motivos que afetaram esse resultado foram vários, mas o resultado final não tem perdão. É bem matemático. E ficou o aprendizado que táticas que usadas no passado(2010)  elas expiram um dia e ai precisamos aprender a criar novas de acordo o quanto nos evoluimos. E talvez foi ai onde falhei.

Para 2012

Neste ano pretendo trabalhar em cima dos “erros” cometidos em 2011, principalmente os mais criticos(já listei e priorizei cada um). E buscar atingir pelo menos 80% das minhas metas. Ah! Não posso esquecer de publicar meu próximo livro que será sobre TDD para iniciantes. O qual começei no final de 2010, mas ainda não deu para finalizar.

E seu 2011/2012?

E vocês já fizeram sua restropectiva do ano de 2011 e já tem 2012 bem definido? Aproveite o inicio do ano passar direcionar onde você pretende chegar até o final do ano que por consequência está alinhado com seus objetivos de médio/longo prazo.

E para concluir quero agradecer a cada leitor pela quantidade de acesso no blog esse ano, apesar de ter blogado menos, o número de acesso aumentou . O report segundo o wordpress para o blog  em 2011 foi como a seguir:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 96,000times in 2011. If it were an exhibit at the Louvre Museum, it would take about 4 days for that many people to see it.

In 2011, there were 17 new posts, growing the total archive of this blog to 202 posts.

The busiest day of the year was June 30th with 1,038 views. The most popular post that day was Pré-Lançamento Guia JEE com Frameworks.

Sinceramente não tenho  palavras para expressa a felicidade em saber que o conteudo postado no blog tem ajudado muitos outros colegas no dia-dia e isso que me deixa bastante feliz e motivado em cada dia escrever um post. Agradeço à todos pelos comentários, as sugestões,críticas etc.

Vou ficando por aqui e até o próximo post.

Abracos, see ya!!