SessionBean + Hibernate, e o Lazy?

Programação Java
#1

Pessoal, vendo algumas discussões aqui no GUJ sobre o uso SessionBeans + Hibernate, fiquei intrigado, como eu lidaria com o a parte de Lazy do Hibernate. O que pensei no primeiro instante seria preencher DTOs nos EJBs e retorná-los para o Cliente. Mas o interessante seria trazer a própria classe do Hibernate, já que a mesma pode ser vista como um DTO, mas ai como ficaria o Lazy no lado do Cliente ?

Alguém teria uma sugestão para fazer sobre esta arquitetura?

#2

Por
que
você
está
usando
DTO?

#3

Já penso que esse é um grande motivo para usar DTO. (claro se estiver distribuido)
Imagine ao acessar os atributos das classes mapeadas pelo hibernate que tem lazy, como isso não iria gerar um overhead.
Nem sei como isso se comportaria…


class EJB 
{
  public Funcionario getFuncionario()
  {
     Funcionario f = session.load();
     return f;
  }
}

// no client

Funcionario f = EJB.getFuncionario();
Iterator  enderecos = f.getEnderecos().iterator();
// imagina isso remoto

Tem outra ele vai passar o objeto serializado…

#4

O cleitne é remoto?

Se for, DTO é o antagonista de lazy-loading. Com DTO você rpecisa de eager-fetching, ou seja: carregar tudo que rpecisa e mandar de uma vez.

#5

Oi Shoes, eu nao estou usando esta solução, pelo menos ainda, rssss, e assim não uso DTO.

Isto é algo que penso se um dia vir a precisar distribuir a minha aplicação, e caso precisando, fiquei preocupado como eu lidaria com o Hibernate.

E no seu segundo POST eu entendi que vc propoe é eu carregar tudo oq preciso, e enviar para o CLIENTE, assim usando as próprias classes do Hibernate, é isto ?

#6

Calma.

Se você não tem clientes remotos, ou seja: em outra JVM, vcoê vai querer evitar ficar fazendo RPC, então é legal empacotar tudo que seu cliente vai precisar e despachar para o dito cujo.

Se você aidna não em isso e está pensando na possibilidade de um dia ter, cuidado para projetar seu sistema para um requisito que nunca existirá, crie uma arquitetura flexível e se rpeocupe com o hoje.

O Hibernate não vai te dar classes para seus objetos de negócio, você tem que persistir seus objetos nele, e pode trabalhar diretamente nestes, sem se preocupar com lazy-loading ou otimizações que o framework faz por trás dos panos.

#7

Entao Shoes, hoje nao tem, mas parece que teremos um projeto, onde uma das exigencias, seja ele funcionar de forma remota. Hoje, eu nao me preocupo com o Hibernate, é super tranquilo a forma de trabalho dele, mas o cliente estando numa outra VM, me preocupa ainda qual a melhor forma de trabalhar com o Hibernate.
#8

Cara passa o DTO como o Shoes falou.
ex:


class Funcionario
{
   private int codigo;
   private String nome;
  // getter and setters
}

class FuncionarioDTO
{
   private int codigo;
   private String nome;
  // getter and setters

}

class EJB 
{
    public FuncionarioDTO getFuncionario()
   {
      Funcionario f = Funcionario.consultar();
      FuncionarioDTO fd = new FuncionarioDTO();
       fd.setCodigo(f.getCodigo());
       fd.setNome(f.getNome());
       return fd;
   }

}

// no client tem desacoplamento ele nem sabe que existe hibernate
FuncionarioDTO fd = EJB.getFuncionario();

A primeira classe é a classe de dominio: esta será persistida e recuperada.
A segunda é uma classe para passar valores do server para o cliente;

#9