Transfer Object

Por isso existem os models ou VOs. Por isso existem os Beans…
Afinal, você não usa um entity para as telas, mas os beans.
Como está a tua estrutura de projeto?

Então, na utilização do TO, as Beans não seriam o próprio TO?

Não.
Beans ficam na camada web, como poderiam ir até a camada de persistência?

Então a estrutura é a seguinte:

Camada de Apresentação - Actions e BusinessDelegate
Camada de Negócio - SessionBeans
Camada de Integração - TOs
Camada de Persistência - DAOs, Entities

Eu estou acostumado com um modelo diferente. A camada de persistência fica abaixo da camada de integração, que conterá as classes e recursos comuns à todas as demais camadas. Ali, o que você chama de TO, eu chamo de VO e alguns de model.
Na camada de persistência, tenho os DAOs e os DTOs (Data Transfer Objects) que utilizam os models nas requisições feitas das camadas inferiores e retornam dados da camada que estão (persistência). São os request/response DTO.
Camada de negócios, onde toda a estrutura lógica é elaborada pelos services e, na camada web, os beans, processors, telas.

Está usando qual framework?

gustavo.toledo:

Bom dia,

Estou desenvolvendo um projeto da faculdade de um gerenciador de fluxo de tráfego aéreo.

Estou usando o Hibernate.

Tenho, por exemplo, uma entidade Voo, que possui relacionamento com a entidade Viagem, logo, tendo um atributo viagem.
Tenho também o respectivo DAO e Transfer Object(TO) da classe Voo.

O VooDAO, no método “findById(int id)” deve retornar um VooTO já preenchido.

Minha dúvida é a seguinte:

Como então, fazer para que o VooTO tenha a Viagem preenchida também, sendo que o TO não pode carregar entidades? Ele pode carregar outro TO? Se sim, teria alguma forma fácil de fazer isto, sem ficar preenchendo TO por TO no DAO?

Simplesmente não use mais TO’s ou VO’s. É só desconectar as entidades do contexto de persistência e envia-los par outras camadas…e vice versa.

Correto FernandoFranzini

tem muito padroes depreciado aii

FernandoFranzini:

gustavo.toledo:

Bom dia,

Estou desenvolvendo um projeto da faculdade de um gerenciador de fluxo de tráfego aéreo.

Estou usando o Hibernate.

Tenho, por exemplo, uma entidade Voo, que possui relacionamento com a entidade Viagem, logo, tendo um atributo viagem.
Tenho também o respectivo DAO e Transfer Object(TO) da classe Voo.

O VooDAO, no método “findById(int id)” deve retornar um VooTO já preenchido.

Minha dúvida é a seguinte:

Como então, fazer para que o VooTO tenha a Viagem preenchida também, sendo que o TO não pode carregar entidades? Ele pode carregar outro TO? Se sim, teria alguma forma fácil de fazer isto, sem ficar preenchendo TO por TO no DAO?

Simplesmente não use mais TO’s ou VO’s. É só desconectar as entidades do contexto de persistência e envia-los par outras camadas…e vice versa.

MVC é para os fracos.
Ele está tentando seguir um pattern da forma como foi ensinado a ele.
É muito simples resolver, quando se ignora toda e qualquer instrução ou regra ou pattern ou bom senso…
Por isso existem sistemas que, quando necessário dar manutenção ou trocar a camada de apresentação, nunca mais funcionam.
O que ele pretende é, independente de usar jsf, jsp, servlets ou swing para fazer as telas é ter certeza que todas as demais camadas estão coesas e funcionais e irão rodar tranquilamente.

Então, o framework é o Struts2 mesmo.

Com a criação da filosofia ORM, muitos patterns do antigo catalogo J2EE(1.3 e 1.4) foram deixados de ser usado por não mais se encaixar com os novos estilos arquiteturais. E esse esquema do TO é um exemplo clássico!
Então gustavo, para corrigir esse impasse arquitetural seu, vc precisa passar a usar o patter EAO - http://www.mindbug.org/2008/03/orm-pattern-merger.html
Procure mais informações…

Então, a arquitetura foi definida pelo próprio professor, junto com os patterns a serem utilizados, porisso do TO.

Sem chances de conseguir algo com o TO, mesmo que mais complexo?

Ai não tem jeito…pq vc esta com uma arquitetura duplicando dados entre objetos desnecessariamente - Entidades para TO e vice versa.

Poxa, complicado… mas obrigado pelas respostas hehehe