Função do DAO

Oi,

O DAO deve ficar responsável única e exclusivamente por fazer a comunicação e tradução entre o mundo SGBD/seilahoquevoceusarprapersistencia e o OO.

Não coloque regras de negócio no DAO, ele não faz parte desta camada!

[]s

Pois é,

A camada DAO é uma camada de integração, certo?

Então serve justamente para akilo que vc disse anteriormente.

Valew

mas tem algumas coisas que não tem como evitar…
pelo menos eu acho…

Ex.:

Tenho um método insertCompany(company)

Quando o usuário de outra camada chama meu método ele
seta os dados de company e dentro de company seta o atributo
employee (atributo do tipo Employee - o 1o. cara da empresa, o cara
de contato, ou simplesmente O Cara).

então, dentro do método eu coloco:

session.save(company);

// log falando que inseriu empresa - regra de negócio do cliente
session.save(userLog);

session.save(employee);

// log falando que inseriu usuário de contato - regra de negócio do cliente
session.save(userLog2);

Quero dizer, aki tem algumas regras dentro da inserção da empresa.
Deste jeito também não estaria de acordo com a função do DAO?

pelo jeito não, pois tem regras de negócio aki…

Então eu faria em método separados???

Com,o eu faria???

valew

abraço

Não sei se é a proximidade do fim do expediente ou pura burrice, mas não entendi sua pergunta

vamos lá…

o que um DAO deveria ter?

criarSeiLahOQue()
removerSeiLahOQue()
atualizarSeiLahOQue()
buscarSeiLahOQue()

Estas funções recebem e retornam objetos a serem persistidos. Estes objetos devem seguir o padrão VO, mas colocar objetos sem funcionalidade fica uma coisa meio procedural [foi o Fowler quem disse isso ou viajei?], então você pode persistir classes com funcionalidades também.

A sua regra está nas classes que são persistidas e nas outras classes da mesma camada. O DAO faz a negócios conversar com os dados de forma mais OO possível.

Uhm…sei lá se te respondi, ams foi

[]s

Boa noite,

Acho que entendi o seguinte:

Ao inserir uma empresa é errado delegar ao escopo do método DAO atribuições de lógica de negócio, como por exemplo, digamos que a empresa é inserida em um cadastro de empresas e que toda empresa é inserida inicialemnte com status de PENDENTE.

O objeto Empresa que tem um atributo, sei lá, EmpresaStatus com idStatus e descricaoStatus, deve ser setado dentro ou fora do método DAO ?

Tipo:

Empresa empresa = new Empresa("ABC");
EmpresaStatus empresaStatus = new EmpresaStatus();
empresaStatus.setIdStatus(PENDENTE);
empresa.setEmpresaStatus(empresaStatus);

ai sim

xxx.inserirEmpresa(empresa);


ou pode ser:

Empresa empresa = new Empresa("ABC");
xxx.inserirEmpresa(empresa);

e dentro do inserirEmpresa ter algo do tipo:
xxx.inserirEmpresa(Empresa empresa);
{

EmpresaStatus empresaStatus = new EmpresaStatus();
empresaStatus.setIdStatus(PENDENTE);
empresa.setEmpresaStatus(empresaStatus);
}

Ah! Só um detalhe…a gente trabalha juntos… :lol:

Uhm…agora cho que entendi…

Estar pendente ou não é um comportamento de quem?

Na verdade, se sua regra de negócios diz que a emrpesa por default é PENDENTE, isto já deveria ser o valor default do atributo status.

O DAO não pode se resposabilizar por este tipo de coisa. O papel dele é [numa inserção, por exemplo]: ‘Ei, você! Pega este objeto e persiste. Não me interessa onde, como, porque, persiste e fica quieto. Quando precisar eu peço de volta’.

Mas, olhando o primeiro post que não entendi com a calma do meu quarto, acho que entendi…

O seu cliente pediu o log quando:
a) os dados fossem inseridos no SGBD
ou
b) Quando o objeto foi criado
?

Se a respsota for a), espero que ele tenha um bom motivo, porque vai complicar a vida em eventual migração, mas tudo bem, é a SUA vida, não a dele

Se for b), o objeto NÃO é criado quando persistido, mas sim quando a classe recebe o ‘new blablabla()’. Seja lá quem criar esta instância, deve ter meios para gerar o log do evento.

Não sei se isto se aplica aqui, mas há algum tempo as pessoas vêm construindo front-ends para SGBDs em toda a parte. A única coisa importante é o BD, tudo são procedures, etc. Levar isso para OO não costuma dar certo. Aidna que dê, no final não é mais OO

Eu escrevi algo sobre DAO no meu blog [link abaixo], vê se te ajuda em algo.

Qualquer coisa, estamos ae, se minha linha dsicada deixar

[]s

Olá pcalcado, blz???

Quanto ao logs, a resposta é A, pois tem um motivo deles.

Mas tem muitas outras coisas que podem ser “retiradas” dos métodos
DAO.

Então, gostaria de saber de você, pra quem deve ser delegado
a parte de negócio?
Tem pattern pra isso não tem???

Muitas coisas estão no modelo, no java bean.
Mas e quanto a fazer cálculos ou outras coisas que no momento
estão, no meu caso, sendo feito dentro do DAO?

valew!

abraço

Tudo trêsquilo

Uhm… cara, acho que o ‘pateern’ neste caso é um só: OO. Você está lidando com objetos, não com registros. Trate os registros como fotografias do seu objeto, não fazem nada mas tem os dados lá [péssima analogia, alguém para melhorá-la?].

Ok, você precisa setar a senha [valor numérico] do cidadão igual à maior senha no BD+1, por exemplo. Quando criar seu objeto, ele [ou algum processo que o crie, tem qeu pensar bem em como dividir responsabildiades aqui…] vai ao DAO e pega esta informação [um método ‘utilitário’ recuperarMaiorSenha(), por exemplo] e seta no objeto.

Delegar coisas de regras de negócio ao DAO é como o fazer em StoredProcedures. Funciona, é rápido, mas é uma merda.

[]s