DAO/Repositorio dentro ou fora do objeto?

This message was edited 3 times. Last update was at 10/09/2008 21:26:26

Tenho o seguinte código no meu modelo de negócios:

Vale a pena optar pela arquitetura abaixo ou isso é trocar 6 por meia duzia?

A implementação do metodo scoreMe é exatamente igual a primeira opção:

This message was edited 1 time. Last update was at 10/09/2008 19:52:55

Na minha opinião:

Prós: o código fica mais orientado a objetos e menos procedural , sendo responsabilidade do usuário dar nota.

Contras: você teria que ter todos os seus objetos usuário com um repositório o que deve aumentar o overhead(uma lista de usuários), e se somente usuários carregados pelo loadById tivessem esse repositório, quebraria o modelo pois eu não poderia chamar scoreMe de qualquer usuário.

Obs: Acho que o método deveria ser score não? Pois o usuário atual da uma nota para outro usuário e não recebe a nota de outro usuário a ação é dar nota.

T+

Rapapel wrote:
Obs: Acho que o método deveria ser score não? Pois o usuário atual da uma nota para outro usuário e não recebe a nota de outro usuário a ação é dar nota.

O usuario passado como parametro é que dá nota para o usuário que está recebendo o método. Se fosse score() pareceria que é o contrário.

Estou a procura de uma boa justificativa para colocar o repository dentro do objeto, mas não encontro... Parece que fica mais bonito na teoria (concordo) mas na prática dá no mesmo no final das contas...

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Usuário esta dando uma nota à outro usuário?

É o mais perto do pensamento humano que consigo chegar sem usar uma Fluent Interface.

E respondendo, dentro do objeto, numa camada mais abaixo, como de costume.

This message was edited 4 times. Last update was at 10/09/2008 22:12:22

Bruno Laturner wrote:Usuário esta dando uma nota à outro usuário?
usuarioQueDaNota.score(nota, usuarioQueVaiReceberANota); //ou usuario.daNotaPara(nota, outroUsuario);
É o mais perto do pensamento humano que consigo chegar.

Assim fica mais intuitivo mesmo. No meu caso o objeto usuário está recebendo uma nota de outro usuário, por isso o scoreMe, ou seja, é o inverso. Poderia ser addScore.

Mas concordo que é melhor não ser contra-intuitivo e fazer do jeito que vc falou, é que o objeto que está dando a nota já está carregado e está na sessão. E o que está na sessão não faz sentido ter repositório nenhum.

Mas isso não tem nada haver com a dúvida do tópico.

Pergunta então: o user que está na sessão (usuário logado) deve ter o repository dentro? Acredito que não...

E o repositório, pode ter um pool de conexões lá dentro de forma que o repositorio possa ficar inativo durante um bom tempo até alguém chamar ele?

Hoje meu pool de conexões fica centralizado num único lugar e o container de IOC injeta as connections nos lugares que ela é necessária, como em um repositório. A questão é que o repositorio só vive enquanto sua connection viver, isto é, cada requisição web pega uma connection usa e devolve para o pool, como tem que ser. Se cada repositorio tiver uma referencia para o pool, então teremos o cenário de uma requisição abrindo várias conexoes diferentes, o que é péssimo.

Então dando rollback e voltando a minha pergunta original. Dentro ou fora e qual a real vantagem se for dentro?

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

saoj wrote:Pergunta então: o user que está na sessão (usuário logado) deve ter o repository dentro? Acredito que não...

Why not?

saoj wrote:E o repositório, pode ter um pool de conexões lá dentro de forma que o repositorio possa ficar inativo durante um bom tempo até alguém chamar ele?

Hoje meu pool de conexões fica centralizado num único lugar e o container de IOC injeta as connections nos lugares que ela é necessária, como em um repositório. A questão é que o repositorio só vive enquanto sua connection viver, isto é, cada requisição web pega uma connection usa e devolve para o pool, como tem que ser. Se cada repositorio tiver uma referencia para o pool, então teremos o cenário de uma requisição abrindo várias conexoes diferentes, o que é péssimo.

Então dando rollback e voltando a minha pergunta original. Dentro ou fora e qual a real vantagem se for dentro além de ficar mais bonito?

Bem, o pool deve ter o controle próprio dele de transações. Na maioria dos casos, cada requisição ao servidor gera uma thread para atendê-la. Num bom controle de conexões, somente uma conexão por thread é criada e utilizada, mais que isso é desperdício.

Considerando que há esse controle eficiente, então essa arquitetura é possível, e considero ser um ótimo exemplo de OO.

Respondendo a pergunta: Além de ficar mais bonito, a vantagem é que você deixará de mexer tanto com persistência, e passará a desenvolver somente para teu negócio.

Vide o primeiro exemplo, lá tinha repositório e negócio. No segundo "eliminamos" o repositório, agora só há negócio.

saoj wrote:
userRepo.scoreUser(id, u.getId(), score); // onde // id = usuario que está recebendo a avaliaçao // u.getId() = usuario que está dando a nota // score = nota

Se for repositório do DDD, que serve para guardar/reconstituir objetos, acho bem estranho o método se chamar scoreUser().

A única coisa que eu faria no exemplo do Bruno é inverter as ordem dos parâmetros para aumentar a expressividade (nesse caso, a fluência do código). Outros exemplos:

Ao invés de injetar um repositorio em Usuario, vc tem a opção de criar um 'domain service' (DDD) como:

Ou, se preferir...

Lembrando que esse service é de domain (domain layer), e, deve ser stateless. Assim, como sua construção é simples e facilmente gerenciado por um IoC container como o Spring (diferente de um Entity, por ex., ainda mais quando se tem um framework ORM envolvido), facilita que seus colaboradores sejam providos com facilidade, como é o caso dos repositórios.
Não confundir com o service layer do fowler.

saoj wrote:
o user que está na sessão (usuário logado) deve ter o repository dentro? Acredito que não...

Pra que repository? Normalmente o 'usuário logado' que fica na session não é o próprio 'usuário', já que são dois conceitos diferentes. 'Usuario logado' deveria ter apenas informações como identidade, permissões, nome completo, nome de usuário, e alguma outra coisa a mais que vale a pena ter deixar na session. Muitas vezes pode ser um 'value object' (!=DTO) criado durante a autenticação. Na realidade, 'usuario logado' e 'usuario' deveriam ser implementados em classes separadas, mas o que acontece na prática é que muita gente usa uma mesma classe para representar dois conceitos diferentes. Isso causa grandes problemas, já que os dois conceitos normalmente possuem diferentes comportamentos/estados, possuem invariantes diferentes, participam de aggregates (DDD) diferentes, etc. E, outra, como ficam os métodos toString(), hashCode(), equals() que não podem ser compartilhados entre os dois conceitos? É o mesmo problema daqueles que reutilizam a classe 'Usuario' para representar dados de login... a única coisa comum entre os dois talvez poderia ser o atributo 'String usuarioLogin', já que a própria senha tem semântica diferente nos dois conceitos (no Usuario provavelmente você tem uma hashSenha, e não exatamente senha). Resumindo, normalmente não faz sentido o 'usuario logado' ter acesso a um repository.

saoj wrote:

Rapapel wrote:
Obs: Acho que o método deveria ser score não? Pois o usuário atual da uma nota para outro usuário e não recebe a nota de outro usuário a ação é dar nota.

O usuario passado como parametro é que dá nota para o usuário que está recebendo o método. Se fosse score() pareceria que é o contrário.

disse com relação a esse método acima de da entidade Usuario, que acho que deveria ser usuarioAtual.daNotaPara(outroUsuario, nota) e não usuarioQueRecebeNota(usuarioQueDaNota, nota).

Boa sorte na pesquisa, se encontrar um bom motivo posta ai pra gente.

T+

This message was edited 1 time. Last update was at 11/09/2008 08:11:50

Gerson wrote:
Ao invés de injetar um repositorio em Usuario, vc tem a opção de criar um 'domain service' (DDD) como:

public class ServicoAvaliacaoImpl implements ServicoAvaliacao{ public void usuarioEhAvaliadoPorOutroUsuario(Usuario usuario, Usuario outroUsuario, int nota){ usuario.ehAvaliadoPor(outroUsuario, nota); repositorioUsuario.salva(usuario); // se não estiver usando um framework ORM } }

Estou por fora de DDD, mas essa implementação de servico é bem parecida com o que eu fiz inicialmente, só que ao invés de usar ServicoAvaliação eu usei o repository mesmo, que nesse caso funciona mais como um DAO mesmo e tb é stateless.

Pra que repository? Normalmente o 'usuário logado' que fica na session não é o próprio 'usuário', já que são dois conceitos diferentes. 'Usuario logado' deveria ter apenas informações como identidade, permissões, nome completo, nome de usuário, e alguma outra coisa a mais que vale a pena ter deixar na session. Muitas vezes pode ser um 'value object' (!=DTO) criado durante a autenticação. Na realidade, 'usuario logado' e 'usuario' deveriam ser implementados em classes separadas, mas o que acontece na prática é que muita gente usa uma mesma classe para representar dois conceitos diferentes. Isso causa grandes problemas, já que os dois conceitos normalmente possuem diferentes comportamentos/estados, possuem invariantes diferentes, participam de aggregates (DDD) diferentes, etc. E, outra, como ficam os métodos toString(), hashCode(), equals() que não podem ser compartilhados entre os dois conceitos? É o mesmo problema daqueles que reutilizam a classe 'Usuario' para representar dados de login... a única coisa comum entre os dois talvez poderia ser o atributo 'String usuarioLogin', já que a própria senha tem semântica diferente nos dois conceitos (no Usuario provavelmente você tem uma hashSenha, e não exatamente senha). Resumindo, normalmente não faz sentido o 'usuario logado' ter acesso a um repository.

Faz um certo sentido isso, mas lembrando que o usuário que está logado será utilizado a todo momento pelo sistema. Se eu guardo só o username ou o id na sessão, eu terei que a todo momento carregar/construir o usuário logado. Então porque não guardar o usuário (sem repositorio) na sessão?

O problema de colocar o repositorio dentro do objeto user é que vc terá que se policiar para nunca chamar um método que depende de um repositório de um usuário que não tem repositorio ou que o repositorio já está stale.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

saoj wrote:Tenho o seguinte código no meu modelo de negócios:

userRepo.scoreUser(id, u.getId(), score); // onde // id = usuario que está recebendo a avaliaçao // u.getId() = usuario que está dando a nota // score = nota

Vale a pena optar pela arquitetura abaixo ou isso é trocar 6 por meia duzia?

O seu objeto userRepo está atuando no sistema (to score é um verbo), portanto ele deveria estar em um objeto do tipo Serviço.
E o serviço deveria ser assim:

This message was edited 2 times. Last update was at 11/09/2008 08:34:03

sergiotaborda wrote:

saoj wrote:Tenho o seguinte código no meu modelo de negócios:

userRepo.scoreUser(id, u.getId(), score); // onde // id = usuario que está recebendo a avaliaçao // u.getId() = usuario que está dando a nota // score = nota

Vale a pena optar pela arquitetura abaixo ou isso é trocar 6 por meia duzia?

O seu objeto userRepo está atuando no sistema (to score é um verbo), portanto ele deveria estar em um objeto do tipo Serviço.
E o serviço deveria ser assim:

public class ScoreService{ public void score(User userToScore, User userThatScored , Score score){ // codigo. } }

Entendi. Eu estou fazendo assim, só que estou colocando tudo no DAO, pois essa modificacao é feita apenas no banco de dados, visto que estou trabalhando apenas com ids nesse caso e nao com os objetos em si.

Mas concordo que o mais certo é o ScoreServce chamar o dao, só que essa replicação de camadas ( action -> servico -> dao) me incomoda um pouco, apesar de na teoria ser a mais certa. Tenho desejos de transformar a minha action desacoplada do framework em serviço, evitando assim uma camada a mais. Seria a opção 4 daqui: http://blogs.mentaframework.org/posts/list/14.page

Isso foge um pouco do tópico, que é sobre colocar ou não o dao/repositorio dentro do objeto, mas é um assunto tb interessante. Colocar uma camada a mais, apenas para fazer uma chamada a outra (dao/repositorio) é bem correto na teoria, mas na prática é um pé-no-saco. Usando um framework loosely coupled acho que dá para, sem prejuízos, fazer a action ter o mesmo papel de serviço.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

saoj wrote:Mas concordo que o mais certo é o ScoreServce chamar o dao, só que essa replicação de camadas ( action -> servico -> dao) me incomoda um pouco, apesar de na teoria ser a mais certa. Tenho desejos de transformar a minha action desacoplada do framework em serviço, evitando assim uma camada a mais. Seria a opção 4 daqui: http://blogs.mentaframework.org/posts/list/14.page

Mas neste caso você não estaria criando uma nova camada. O ScoreService neste caso é uma classe de domínio. É um pouco diferente destas fachadas que se tem usado por aí.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

saoj wrote:
Entendi. Eu estou fazendo assim, só que estou colocando tudo no DAO, pois essa modificacao é feita apenas no banco de dados, visto que estou trabalhando apenas com ids nesse caso e nao com os objetos em si.

Então o seu programa não é orientado ao dominio e sim ao banco. Nesse caso o seu objeto userRep deveria se chamar userDAO.
Ao usar Repositorio vc está implicitamente dizendo que o sistema é orientado ao dominio e colocar ações no repositorio é automáticamente incoerente.

Mas concordo que o mais certo é o ScoreServce chamar o dao, só que essa replicação de camadas ( action -> servico -> dao) me incomoda um pouco, apesar de na teoria ser a mais certa. Tenho desejos de transformar a minha action desacoplada do framework em serviço, evitando assim uma camada a mais. Seria a opção 4 daqui: http://blogs.mentaframework.org/posts/list/14.page

Isso foge um pouco do tópico, que é sobre colocar ou não o dao/repositorio dentro do objeto, mas é um assunto tb interessante. Colocar uma camada a mais, apenas para fazer uma chamada a outra (dao/repositorio) é bem correto na teoria, mas na prática é um pé-no-saco. Usando um framework loosely coupled acho que dá para, sem prejuízos, fazer a action ter o mesmo papel de serviço.

Uma action nunca será decoupled do framework. Basta que vc tenha que ler o ID do request para que isso seja verdade. E não me refiro ao objeto Request mas ao conceito request. Dito de outra forma, a sua action funcionaria em um programa swing ? Não ? Então ela está acoplada. O Serviço, por definição, não está acoplado. Se está acoplado não é um serviço.
O uso de uma camada de serviços tem dois objetivos : 1) encapsular as lógicas que alteram estado do sistema 2) tornar o dominio desacoplado da estrutura da aplicação, i.e. permitindo que ele seja usado em outro ambiente tecnológico.

A única forma de desacoplar o Serviço da infra é ter algum objeto que traduz a infra em objetos do dominio e os passa ao Serviço.
Então a sua action deveria pegar o ID do request, obter o usuário correspondente via Repositorio e passar ao Serviço já montado.

Se a sua aplicação é orientada a banco ignore o que eu falei, mas chame os objetos de DAO e não de Repositorio.
Neste caso tb não faz sentido colocar lógicas nos objetos e sim , ficariam no DAO.

Para coisas simples isto pode funcionam e pode até parecer elegante, mas não é. As poucas camadas significam que o sistema é amarrado.

sergiotaborda wrote:

saoj wrote:
Entendi. Eu estou fazendo assim, só que estou colocando tudo no DAO, pois essa modificacao é feita apenas no banco de dados, visto que estou trabalhando apenas com ids nesse caso e nao com os objetos em si.

Então o seu programa não é orientado ao dominio e sim ao banco. Nesse caso o seu objeto userRep deveria se chamar userDAO.
Ao usar Repositorio vc está implicitamente dizendo que o sistema é orientado ao dominio e colocar ações no repositorio é automáticamente incoerente.

Mas concordo que o mais certo é o ScoreServce chamar o dao, só que essa replicação de camadas ( action -> servico -> dao) me incomoda um pouco, apesar de na teoria ser a mais certa. Tenho desejos de transformar a minha action desacoplada do framework em serviço, evitando assim uma camada a mais. Seria a opção 4 daqui: http://blogs.mentaframework.org/posts/list/14.page

Isso foge um pouco do tópico, que é sobre colocar ou não o dao/repositorio dentro do objeto, mas é um assunto tb interessante. Colocar uma camada a mais, apenas para fazer uma chamada a outra (dao/repositorio) é bem correto na teoria, mas na prática é um pé-no-saco. Usando um framework loosely coupled acho que dá para, sem prejuízos, fazer a action ter o mesmo papel de serviço.

Uma action nunca será decoupled do framework. Basta que vc tenha que ler o ID do request para que isso seja verdade. E não me refiro ao objeto Request mas ao conceito request. Dito de outra forma, a sua action funcionaria em um programa swing ? Não ? Então ela está acoplada. O Serviço, por definição, não está acoplado. Se está acoplado não é um serviço.
O uso de uma camada de serviços tem dois objetivos : 1) encapsular as lógicas que alteram estado do sistema 2) tornar o dominio desacoplado da estrutura da aplicação, i.e. permitindo que ele seja usado em outro ambiente tecnológico.

A única forma de desacoplar o Serviço da infra é ter algum objeto que traduz a infra em objetos do dominio e os passa ao Serviço.
Então a sua action deveria pegar o ID do request, obter o usuário correspondente via Repositorio e passar ao Serviço já montado.

Se a sua aplicação é orientada a banco ignore o que eu falei, mas chame os objetos de DAO e não de Repositorio.
Neste caso tb não faz sentido colocar lógicas nos objetos e sim , ficariam no DAO.

Para coisas simples isto pode funcionam e pode até parecer elegante, mas não é. As poucas camadas significam que o sistema é amarrado.

Obrigado. Dá mais trabalho fazer assim, principalmente quando a aplicação naturalmente possui a tendência de ser orientada a banco-de-dados (babá de DB). Mas o que vc falou é o mais correto...

sergiotaborda wrote:

O seu objeto userRepo está atuando no sistema (to score é um verbo), portanto ele deveria estar em um objeto do tipo Serviço.
E o serviço deveria ser assim:

public class ScoreService{ public void score(User userToScore, User userThatScored , Score score){ // codigo. } }

O que faz ser um domain service não é o 'userRepo' estar atuando no sistema (afinal de contas, tudo está atuando no sistema), e, muito menos, o nome do método ser um verbo (deve ser um verbo!).
Afinal de contas, o que você quis dizer?

Notícias, artigos e o maior fórum brasileiro sobre Java