Join em DAO

Programação Arquitetura
#1

Caros Amigos,

Estou reescrevendo um serviço que está num linguição todo linear e passando para OO. Como referência, estou me baseando no Core J2EE Patterns http://java.sun.com/blueprints/corej2eepatterns/index.html.

A minha dúvida é a seguinte: no DAO, temos os TO para navegar as informações que saem do BD para outros lugares. Então, cada tabela teria um TO e o mundo seria perfeito. Mas no caso de um Join, o que é melhor? Criar um TO do acesso ou incorporar um TO em outro? Ou outra coisa mais “elegante”?

Exemplo:

Join

SELECT f.nome_funcionario, d.nome_departamento
FROM    tbFuncionario f, tbDepartamento d
WHERE  f.codigo_funcionario = <codigo>
AND      f.codigo_departamento_funcionario = d.codigo_departamento

TOs

public Class funcionario
{
    private long codigo;
    private String nome;

    public getters() / public setters()
}

public Class departamento
{
    private long codigo;
    private String nome;

    public getters() / public setters()
}

A dúvida, um TO pro join…

public Class funcionarioDepartamento
{
    private String nomeFuncionario;
    private String nomeDepartamento;

    public getters() / public setters()
}

Ou um TO que acople o outro…

public Class funcionario
{
    private long codigo;
    private String nome;
    private Departamento departamento;

    public getters() / public setters()
}

Ou até mais, um que extenda o outro…

public Class funcionario extends departamento
{
    private long codigoFuncionario;
    private String nomeFunctionario;

    public getters() / public setters()
}

public Class departamento
{
    private long codigoDepartamento;
    private String nomeDepartamento;

    public getters() / public setters()
}

Ou alguma outra solução mais elegante…

Senhores, obrigado pela opinião desde já. 8)

#2

Não seria melhor vc ter uma classe Departamento que possua uma lista de Funcionários?

E o Funcionário teria um Departamento.

Parecido com os mapeamentos do Hibernate, mas vc seta eles na hora que vc precisar em alguma função do seu Dao…

public void loadFuncionario(Funcionario funcionario){

          ....

          Departamento dep = new Departamento();
          dep.setNome("Nome que veio no resultSet");
          
         funcionario.setNome("Nome que veio no resultSet");
         funcionario.setDepartamento(dep);

         ....
}

Ou algo parecido

#3

Se fosse eu criaria um VOA contendo as informações do TO’s e usaria interfaces para controlar os métodos.

Ex:

public interface IFuncionario extends Seriazable {
}

public interface IDepartamento extends Seriazable {
}

public class FuncionarioVO implements IFuncionario {
}

public class DepartamentoVO implements IDepartamento {
}


public class FuncionarioDepartamentoVOA implements IFuncionario, IDepartamento {
}
#4

Converter código legado é bem difícil, mas vamos tentar.

[quote=sr.sucesso]
A minha dúvida é a seguinte: no DAO, temos os TO para navegar as informações que saem do BD para outros lugares. Então, cada tabela teria um TO e o mundo seria perfeito. Mas no caso de um Join, o que é melhor? Criar um TO do acesso ou incorporar um TO em outro? Ou outra coisa mais “elegante”?[/quote]

Você não precisa do TO. Busque no fórum sobre DTO e você saberá porque.

<nota-mental>escrever sobre técnicas de mapeamento o-r e padrões</nota-mental>

Esquecendo os (D)TOs, como é sua hierarquia de objetos? Como você relaciona os objetos e as tabelas?

Shoes

#5

Quando escrever passa o link pra gente, esse é um assunto dos que mais tenho dúvida. ( Em um mundo sem hibernate, como lidar com a persitência de modo OO ? )

#6

Será que se o join for muito utilizado não vale a pena criar uma view no banco ?

#7

É melhor vc pensar do ponto de vista dos objetos e suas hierarquias antes de pensar em join.
Vc está criando uma estrutura para satisfazer seu banco de dados mas eu acho que vc deve fazer o inverso.
ex:


class Funcionario {
  Departamento departamento;
}

Departamento está associado a Funcionário aí como vc vai recupera-lo é outra história…

#8

Não, não é. É feito somente pra esse serviço. Não vale a pena.

VOA é um termo novo pra mim… vou pesquisar…
DTO deve ser bacana… vou pesquisar tb…

Só pra deixar bem claro, o meu intuito não é reinventar a roda e sim aproveitar a oportunidade de estar reescrevendo o serviço e deixar ele mais profissional… por isso fui procurar nos Patterns uma forma melhor de criação… só o lance do Join que me deixou em dúvida, pois no pattern ele não menciona nada… dá até impressão que se seguir exatamente aquela regra eu teria que puxar um Collection do Funcionario, um Collection do Departamento e fazer o Join na mão… :shock:

(…)

#9

Se vc usar o hibernate é facil, agora com o JDBC dá para fazer mas vc vai ter que usar umas gambiarras…
Use o hibernate vai ficar mais facil…

#10

[quote=jprogrammer]É melhor vc pensar do ponto de vista dos objetos e suas hierarquias antes de pensar em join.
Vc está criando uma estrutura para satisfazer seu banco de dados mas eu acho que vc deve fazer o inverso.
ex:


class Funcionario {
  Departamento departamento;
}

Departamento está associado a Funcionário aí como vc vai recupera-lo é outra história…
[/quote]

Acho que entendi. Vc quer dizer que estou pensando na hierarquia errada… Não é o Funcionario que tem o departamento, e sim um departamento que tem vários funcionários… certo?

Ficaria essa ligação dentro das classes… ou não? :?:

#11

[quote=jprogrammer]Se vc usar o hibernate é facil, agora com o JDBC dá para fazer mas vc vai ter que usar umas gambiarras…
Use o hibernate vai ficar mais facil…
[/quote]

Para esse trabalho que estou fazendo não vale a pena usar o Hibernate, já que são poucos acessos… mas como informação vou pesquisar… valeu!

#12

[quote=sr.sucesso]
Não é o Funcionario que tem o departamento, e sim um departamento que tem vários funcionários… certo?

Ficaria essa ligação dentro das classes… ou não? :?: [/quote]

Acho que o Funcionario pode ter um Departamento e um Departamento possuir a lista de Funcionários.

public class Funcionario {
      ...
      public void setDepartamento(Departamento d){
             this.departamento = d;
             d.addFuncionario(this);
      }
}

E algo bem semelhante caso vc adicione um funcionario ao departamento.

#13