Estruturar relacionamento para exibição

Exibir dados de um join em 3 tabelas ou exibir dados de 3 classes relacionadas?
Se o caso for o primeiro , esqueça o MER, procure pensar sempre em objetos e a interação entre eles.

Se o caso for o segundo, ai depende, eu costumo deixar os meus objetos compostos “leves” ( http://www.martinfowler.com/eaaCatalog/lazyLoad.html ).

1 (um) SELECT, que retorna um JOIN de 3 (três) tabelas do meu banco, que são representadas por 3 (três) entidades (classes distintas) na minha aplicação.

Como se fosse assim:
Classe: Cliente (Codigo, Nome)
Classe: Vendedor (Codigo, Nome)
Classe: Venda (CodigoCliente, CodigoVendedor, Valor)

Essas seriam minhas classes, e são identicas às tabelas do Banco.

Se eu fosse manipular Clientes (select * from Clientes) por exemplo, eu faria um método para me retornar um List

A minha dúvida é como proceder para manipular uma união entre essas entidades.
Com uma consulta assim:
“select A.NOME, B.NOME, C.VALOR
from CLIENTE A, VENDEDOR B, VENDA C
where (A.CODIGO = C.CODIGOCLIENTE) and
(B.CODIGO = C.CODIGOVENDEDOR)”

A implementacao do seu DAO para Cliente, Vendedor e Venda deve fornecer todo o interfaceamento (de interface) para a sua base de dados, ou seja, se vc implementou o pattern dao, os comandos sql morreram ali. Dai pra frente voce vai lidar com objetos.
No caso, levando em consideracao o seu select, uma venda e composta por um clientge e um vendedor, certo?
Entao faca com o que o dao da venda “monte” o objeto venda completamente (ele sai de la com o objeto cliente e venda ja associado, lembre de utilizar os daos de cliente e vendedor para montar o os respectivos objetos)

//no dao da venda ...

public Venda getById(Sting id){
    //select em tabela vendas de acordo com a id e monto o objeto venda
    new Venda(parametros aqui)
    
    new daoVendedor()
    vendedor = daoVendedor.getById(id que veio do outro select)
    venda.setVendedor(vendedotr)
    
    return venda //ja montado completamente
}

Deu pra ver que cansa, ne. Sem contar que existem outros problemas.Coisa do tipo: numa colecao de produtos vendidos, quem esta persistido e quem nao esta? Quem foi alterado?

DAO Pattern (em pt-BR):
http://www.javafree.org/content/view.jf?idContent=183
E, depois, da uma olhada nesse catalogo:
http://www.martinfowler.com/eaaCatalog/
Tem umas coisas ai que vao te ajudar a montar um dominio bacana e livre de logica relacional.

Humm, acho que entendi.

Neste caso, minha classe venda não deveria ter os atributos “Codigo do Cliente” e “Codigo do Vendedor”, mas sim um atributo que fosse Cliente (da minha classe Cliente).

É isso?

Neste caso eu vejo a necessidade de ter métodos distintos dos “getById” (normais) senão sempre vou fazer SELECTs que pegam todos os campos de forma desnecessária.
Neste exemplo que eu dei por exemplo, um método que devolvesse um objeto “Cliente” só com o “Nome” para preencher meu objeto "Venda.

Isso e não isso.
Se acontecer de um objeto possuir uma coleção muito grande, ou esse objeto possuir outros associados (e cascata vai indo), você não vai querer ter todos eles na memória, nesse caso uma solução possível seria usar lazy load.

Sim , provavelmente você terá muitos outros métodos de busca além do byId, mas eu não sei se é boa idéia devolver um objeto cliente apenas com o nome. Se você tem o nome do camarada é quase certo que foi feita uma busca na tabela dos clientes, porque não pegar logo “tudo” relacionado ao cliente? A diferença entre select field e select field field field field é minima/inexistente.