Repositório, Dao e sua relação com a Entidade...

Salve galera !

Como alguns aqui já sabem (ou ao menos me viram no fórum nos últimos dias) estou tentando melhorar minha visão sobre OO para depois começar a me aprofundar mais em designer patters, porque senão vira uma sopa.

Então, por isto, li bastante ontem aqui no fórum e alguns blogs e sites - com destaque pro Fragmental do Phillip, o blog da Caelum e o Search do fórum.

Depois de muito ler, criei um modelo de aplicativo que simplesmente seta uns dados e "persiste-os" num possível database.
Tentei implementar: Repository, evitar os get/set burros, Dao (que não sei se seria bem esse o nome) além da Entidade. Abaixo o código:

Programa de teste

Nele eu usei o construtor da Entidade Pessoa para popular meu objeto com o nome e idade. Depois tento persisti-lo no banco de dados (que não existe) e entao pergunto ao objeto Pessoa se "ele" é maior de idade, ao invés do if(maluco.getIdade() >= 18 ) diretamente no programa teste.

A Interface

A Dao que a implementa...

e a entidade...

Agora, gostaria de tirar algumas dúvidas, se for possível...

1. A partir do momento que a "DAO" implementa o "Repository" e eu na entidade Pessoa.setRepositorio exijo que o parametro seja a Interface, eu estou "codificando para uma interface ao invés de para uma implementação" como muitos dizem ser o mais correto ?

2. no Pessoa.adiciona, eu passo para o Pessoa.setRepositorio a DAO, uma vez que não posso passar a Interface, pois ela não é algo "concreto". Essa implementação estaria correta ?

3. Quanto aos get/setters: eu usei apenas o getNome() pois no programa eu precisaria exibir o nome dele, porém não criei o getIdade. Só que ao "persistir" lá na DAO eu precisaria ter *todos* os getters para passar ao Statement do DB para ele poder gravar, além de usar *boa parte* deles para a View. Isso não seria um pecado, ou seria ?

Acho que são "apenas" estes fantasmas que rondam minha cabeça por hora. Se alguém puder comentar algo também, será de grande valia!

Abraços!

Cara dê uma lida nesse link.

http://www.javafree.org/content/view.jf?idContent=183

Abraço!

This message was edited 1 time. Last update was at 06/10/2008 06:31:08

Oi,

Suas dúvidas não possuem muito a ver com Domain-Driven Design -lembre-se que DDD não é só usar meia dúzia de padrões ou nomes- então vou me ater ao uso de interfaces e não à semântica delas.

hlegius wrote:
1. A partir do momento que a "DAO" implementa o "Repository" e eu na entidade Pessoa.setRepositorio exijo que o parametro seja a Interface, eu estou "codificando para uma interface ao invés de para uma implementação" como muitos dizem ser o mais correto ?

Sim. Você está trabalhando com o conceito e não com a implementação, o que geralmente é algo bom.

(dica: por que você precisaria do Repositório dentro da Pessoa?)

hlegius wrote:
2. no Pessoa.adiciona, eu passo para o Pessoa.setRepositorio a DAO, uma vez que não posso passar a Interface, pois ela não é algo "concreto". Essa implementação estaria correta ?

Seu objeto pessoa trabalha com o conceito Repositório e não com a implementação DAO. Isso é uma coisa boa mas instanciar a implementação dentro do objeto destrói este desacoplamento. A maneira comum de fazer isto em Java é ter uma terceira entidade que ou é perguntada quando você precisa de uma implementação ou injeta a implementação na sua classe. Nos dois modos sua classe lida apenas com a interface e nunca com a implementação.

Para saber mais procure sobre o padrão Registry e sobre Dependency Injection.

hlegius wrote:
3. Quanto aos get/setters: eu usei apenas o getNome() pois no programa eu precisaria exibir o nome dele, porém não criei o getIdade. Só que ao "persistir" lá na DAO eu precisaria ter *todos* os getters para passar ao Statement do DB para ele poder gravar, além de usar *boa parte* deles para a View. Isso não seria um pecado, ou seria ?

Se você estiver utilizando JDBC ou algum framework mais antigo (ou com uma abordagem diferente) você vai precisar de tais getters. A solução neste caso pode ser tanto ter os getters na classe (dependendo do caso não faz sentido complicar) ou fazer Pessoa ser uma interface que Não expõe o getIdade() mas que é implementada por uma classe que o faz. A solução ideal depende do caso.

Mas a melhor solução seria, certamente, utilizar uma abordagem moderna com Hibernate que não vai te obrigar a fazer estas coisas.

Dica: esqueça Domain-Driven Design por algum tempo e concentre-se em design Orientado a Objetos.

truck1n,
Sua recomendação esclareceu bem a idéia ! DAO não é o fim, é um meio ao que pude entender. Com isso, após a DAO que é uma interface vem sua real implementação seja ela em JDBC, TXT, XML, enfim, a persistência "real".

pcalcado,

pcalcado wrote:Sim. Você está trabalhando com o conceito e não com a implementação, o que geralmente é algo bom.

(dica: por que você precisaria do Repositório dentro da Pessoa?)

Legal. Menos um fantasma. Mas diga-me, essa "dica" significa que não haveria motivos "reais" para uma Pessoa implementar um Repositório ? Pelo que li à fora, Repository é útil quando você tem uma entidade, no caso Pessoa, persistindo informações em diferentes DAO's uma vez que cada DAO tem a reponsabilidade de "cuidar" de um meio - database, xml, txt.. - e no caso mais especifico de db, cada DAO cuidaria de "uma tabela", correto ? Ou eu viajei demais nas leituras ?

pcalcado wrote:Para saber mais procure sobre o padrão Registry e sobre Dependency Injection.

Eu li, na verdade passei a manhã toda lendo sobre isto e pensando em possíveis implementações. A Dependency Injection (como abrevia isto ?) pode ser implementada de várias formas: construtor, interface ou injetando via setter. Hum ! Poderia eu também implementar esse "RepositoryImpl" usando uma fábrica, não ?

Só uma coisa não bateu ainda: esse "RepositoryImpl" seria para cada entidade da aplicação, logo, eu teria que ter outra interface para ele. Resumindo: ainda é uma "sopa" para mim. Busquei alguns exemplos, porém, tá complicado digerir essa ponte entre a camada de negócio e a camada de persistência... sequer consegui implementar alguma coisinha no meu "programinha exemplo" que postei lá no começo... alguma sugestão por onde começar ?

pcalcado wrote:Dica: esqueça Domain-Driven Design por algum tempo e concentre-se em design Orientado a Objetos.

Sim. Estou tentando focar em partes para realmente entender as implementações e saber aplicar caso-a-caso, acho que com isso estou fugindo de aplicar padrões as cegas programas à fora, penso eu.

ah sim! Sobre os getters então não há pecado algum. Desde que eles não sejam inúteis, não haverá problema. (y)

Agradeço a força!

Abraços!

Bom... depois de procurar mais infos, montei a seguinte idéia:

Objeto Pessoa tem injetado via setter um RepositorioImpl
RepositorioImpl <implementa> Repositorio para que tal obedeça o contrato
O repositorioImpl contém as chamadas às Daos Necessárias para fazer a persistência do objeto, ou seja, se para persistir o Objeto Pessoa eu precisar de 2 tabelas distintas + umas configs no XML, eu chamaria 2 ou até 3 implementações de DAO's para que cada uma delas execute sua tarefa própria que seria mapear o objeto para um sistema relacional (database) e uma outra DAO para persistir dados no XML.

Pelo que entendi de repositório seria isto. Ele abstrai diferentes DAO's para que a entidade não saiba o que tem por trás daquele repositório.

Abraço!

Oi,

hlegius wrote:
Legal. Menos um fantasma. Mas diga-me, essa "dica" significa que não haveria motivos "reais" para uma Pessoa implementar um Repositório ? Pelo que li à fora, Repository é útil quando você tem uma entidade, no caso Pessoa, persistindo informações em diferentes DAO's uma vez que cada DAO tem a reponsabilidade de "cuidar" de um meio - database, xml, txt.. - e no caso mais especifico de db, cada DAO cuidaria de "uma tabela", correto ? Ou eu viajei demais nas leituras ?

Por isso que eu disse: esqueça Domain-Driven Design por enquanto e se concetre em design orientado a objetos. Um repositório é algo bem diferente do que você mencionou mas acho que só é possível entender quando se entende a Camada de Negócios.

De qualquer modo, sobre seu exemplo em específico, não há necessidade da pessoa conhecer seu repositório, essa relação não faz parte do domínio e foi criada apenas para facilitar a vida do programador.

hlegius wrote:Eu li, na verdade passei a manhã toda lendo sobre isto e pensando em possíveis implementações. A Dependency Injection (como abrevia isto ?) pode ser implementada de várias formas: construtor, interface ou injetando via setter. Hum ! Poderia eu também implementar esse "RepositoryImpl" usando uma fábrica, não ?

Um container de dependências é como uma fábrica genérica de objetos.

hlegius wrote:
Só uma coisa não bateu ainda: esse "RepositoryImpl" seria para cada entidade da aplicação, logo, eu teria que ter outra interface para ele. Resumindo: ainda é uma "sopa" para mim. Busquei alguns exemplos, porém, tá complicado digerir essa ponte entre a camada de negócio e a camada de persistência... sequer consegui implementar alguma coisinha no meu "programinha exemplo" que postei lá no começo... alguma sugestão por onde começar ?

Vai ser complicado mesmo no início. Você precisa entender melhor como Camadas são organizadas e como objetos são injetados. Como falei, acho que agora é melhor você esquecer Repositórios e começar pelo básico.

hlegius wrote:Bom... depois de procurar mais infos, montei a seguinte idéia:
Objeto Pessoa tem injetado via setter um RepositorioImpl
RepositorioImpl <implementa> Repositorio para que tal obedeça o contrato
O repositorioImpl contém as chamadas às Daos Necessárias para fazer a persistência do objeto, ou seja, se para persistir o Objeto Pessoa eu precisar de 2 tabelas distintas + umas configs no XML, eu chamaria 2 ou até 3 implementações de DAO's para que cada uma delas execute sua tarefa própria que seria mapear o objeto para um sistema relacional (database) e uma outra DAO para persistir dados no XML.

Pelo que entendi de repositório seria isto. Ele abstrai diferentes DAO's para que a entidade não saiba o que tem por trás daquele repositório.

Não. Um repositório é apenas onde você guarda os objetos, ele não necessariamente abstrai nada. Apesar de mais uma vez recomendar que você esqueça repositórios, um Repositório vai estar ligado com um Aggregate Root e dependendo de como você armazena seus entities e value objects ele pode ou não abstrair seus DAOs.

Para começar, crie aplicações que possuem apenas uma Camada de Serviço usando DAOs para persistir objetos de negócio. Entender Domain-Driven Design sem experiência nisso é difícil porque quase toda a literatura foi criada para pessoas experientes.

pcalcado wrote:Por isso que eu disse: esqueça Domain-Driven Design por enquanto e se concetre em design orientado a objetos. Um repositório é algo bem diferente do que você mencionou mas acho que só é possível entender quando se entende a Camada de Negócios.

Okay! o "design orientado a objetos" que você diz é como a camada de negócios funciona ? Não entendi bem essa definição...

pcalcado wrote:Não. Um repositório é apenas onde você guarda os objetos, ele não necessariamente abstrai nada. Apesar de mais uma vez recomendar que você esqueça repositórios, um Repositório vai estar ligado com um Aggregate Root e dependendo de como você armazena seus entities e value objects ele pode ou não abstrair seus DAOs.

Sim. Depois que vi outros posts aqui no Guj onde você fala sobre a camada de negócios e sua relação com a persistência. Você falava que para a camada de negócios, uma vez em memória para sempre em memória, pois ela não "espera" que vá ser descarregada.

pcalcado wrote:Para começar, crie aplicações que possuem apenas uma Camada de Serviço usando DAOs para persistir objetos de negócio. Entender Domain-Driven Design sem experiência nisso é difícil porque quase toda a literatura foi criada para pessoas experientes.

Então você recomenda que eu foque mais na camada de negocios e seu funcionamento, e por hora persista os dados diretamente na camada de negócios ?

Agradeço as dicas. Vou atrás disso com certeza!

Abraços!

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

hlegius wrote:
A Interface

public interface PessoaRepository { public int salva(Pessoa maluco); }

A Dao que a implementa...

public class PessoaDao implements PessoaRepository { public int salva(Pessoa maluco) { System.out.println(maluco.getNome() + " foi persistido no database"); return 1; // seria o id do novo maluco, talvez =) } }

Porque a interface é PessoaRepository e a implementação PessoaDAO ?
Se o DAO é o mesmo que um Repositorio use apenas uma das palavras.

ou

Por outro lado, qual é a responsabilidade de um DAO ?
E qual é a responsabilidade de um Reposiotorio ?
Posso ter um XMLDAO ? E um XMLRepository ?

PessoaDAO e PessoaRepository são o mesmo objeto ? Têm a mesma responsabilidade ? São baseados nos mesmos padrões ?

Pense nisso...

O DAO é um serviço de preservação de dados. Ele media a interação do sistema java com depósitos de dados através do uso de uma ou mais API especificas para esse tipo de deposito. O nome da implementação do DAO está ligado À tencologia que ele usa e/ou ao tipo de deposito que usa. Nomes como XMLDAO (arquivos XML), JDBCDAO (uso de JDBC) , LDAPDAO (usa LDAP) ou DataBaseDAO são válidos.

Vc teria um PessoaDAO e um JDBCPessoaDAO que é a implementação de PessoaDAO que usa JDBC para comunicar com o banco.
Vc pode ter ainda extenções de JDBCPessoaDAO para cada banco de dados. assim teriamos por exemplo OracleJDBCPessoaDAO
e SQLServer2005JDBCPessoaDAO.

O Repositório é um objeto permite aos objetos das entidades encontrarem outros objetos de entidade. Ele são modelados como se fossem coleções de dados com métodos especiais para procurar esses dados. Eles não são desenhados para serem um fachada para a preservação dos dados, mas na prática é util que sejam. Os repositórios funciona para uma certa entidade e são independentes da forma de preservação utilizada. Vc terá um PessoaRepository, mas nunca um XMLRepository porque isso significaria que o seu sistema tem uma entidade chamada XML (poderia, mas é incomum).

hlegius wrote:
Okay! o "design orientado a objetos" que você diz é como a camada de negócios funciona ? Não entendi bem essa definição...

Não exatamente. Não apenas como esta camada funciona mas como objetos, em qualquer camada ou mesmo sem camadas, devem ser projetados. Talvez isso ajude a entender:

http://fragmental.tw/2008/09/23/object-oriented-design-which-how-and-what/

hlegius wrote:

pcalcado wrote:Não. Um repositório é apenas onde você guarda os objetos, ele não necessariamente abstrai nada. Apesar de mais uma vez recomendar que você esqueça repositórios, um Repositório vai estar ligado com um Aggregate Root e dependendo de como você armazena seus entities e value objects ele pode ou não abstrair seus DAOs.

Sim. Depois que vi outros posts aqui no Guj onde você fala sobre a camada de negócios e sua relação com a persistência. Você falava que para a camada de negócios, uma vez em memória para sempre em memória, pois ela não "espera" que vá ser descarregada.

Sim mas isso não faz com que o objeto precise ter uma instância de seu repositório/DAO dentro dele. Procure ler sobre Service Layer e Façade.

hlegius wrote:
Então você recomenda que eu foque mais na camada de negocios e seu funcionamento, e por hora persista os dados diretamente na camada de negócios ?

Mais ou menos. Minha recomendação neste caso é que não procure entende Domain-Driven Design sem entender como criar uma aplicação Orientada a Objetos "normal" (i.e. que não usa diretamente os conceitos de DDD)

This message was edited 1 time. Last update was at 07/10/2008 17:15:21

sergiotaborda,

sergiotaborda wrote:Por outro lado, qual é a responsabilidade de um DAO ?
E qual é a responsabilidade de um Reposiotorio ?

No que pude entender por nas leituras por aí, DAO seria a implementação da persistência, ou seja, o cara que salva em disco nosso objeto - ou como o Shoes disse num post: coloca-os para dormir X)

O repositório ao que entendi é uma interface dessas DAO's. Ele é único para a entidade (no exemplo Pessoa) e é ele que faz a comunicação com as DAO's existentes MySQLPessoaDAO, XMLPessoaDAO, etc.
Só que por exemplo: supondo que o objeto Pessoa ao ser persistido, necessite que: seja persistido o objeto no Database e que salve num XML, por exemplo, a hora em que ele foi persistido. São 2 rotinas: database e XML (exemplo beeem irreal, mas só pra constar mesmo). Neste caso surreal, o Repository iria servir "apenas" como uma façade para o XMLPessoaDao e JDBCPessoaDao ? Ou ele executa outra tarefa ? Veja, explico em código rapidinho:

Estaria essa idéia sobre o Repository correta, ou não tem nada a vê ? Realmente parece uma pattern simples mas digeri-la não está sendo fácil como as demais que tenho lido =~

sergiotaborda wrote:O Repositório é um objeto permite aos objetos das entidades encontrarem outros objetos de entidade. Ele são modelados como se fossem coleções de dados com métodos especiais para procurar esses dados.

Nesta sua explicação você diz que o Repositório permite uma entidade encontrar outra a qual tenha relação. Isso seria algo como: a entidade "Inventario" usa o RepositorioProdutos para localizar Produtos com certas especificações e retornar a coleção desses Produtos para ela ? OU ela usaria o RepositorioInventario e este conectaria-se às interfaces das DAO's dos Produtos para retornar um Produto[*] ?
Se for isto, a coleção seria "criada" no Repositório e devolvida já montada (num vetor, ou algo do tipo) pronto para o "Inventario", certo ? Assim eu teria que alterar somente o RepositorioProduto em caso de atualização na entidade Produto, penso.

pcalcado,

pcalcado wrote:Não apenas como esta camada funciona mas como objetos, em qualquer camada ou mesmo sem camadas, devem ser projetados.

É verdade. Eu ainda estou engatinhando nisto. Programar, programo faz um tempinho, mas aprofundar da forma correta em OO estou começando agora, por isso essa dificuldade em pegar as manhas.

pcalcado wrote:Sim mas isso não faz com que o objeto precise ter uma instância de seu repositório/DAO dentro dele. Procure ler sobre Service Layer e Façade.

Certo. Li a pattern façade e me pareceu bem simples. É uma interface que manipula outras interfaces com o objetivo de simplificar uma rotina. A grosso modo seria algo como eu ter 3 tarefas a seguir em passos, só que ao invés de chamá-las separado, posso "juntá-las" numa façade e rodar apenas um comportamento.

Assim, sendo a pattern repository aplicada como uma façade, eu teria apenas que chamá-la dentro da minha entidade usando o comportamento estático da minha Repository e ela que iria fazer o serviço sujo, apenas me retornando - ou não - algo no fim.

pcalcado wrote:Mais ou menos. Minha recomendação neste caso é que não procure entende Domain-Driven Design sem entender como criar uma aplicação Orientada a Objetos "normal" (i.e. que não usa diretamente os conceitos de DDD)

Tranquilo. Estou seguindo em partes como criar uma aplicação "OO pura" para ver e entender ela primeiro para depois entrar nas patterns mais complexas. Step by step X)

Agradeço muito a força !

Abraços!

hlegius wrote:
Assim, sendo a pattern repository aplicada como uma façade, eu teria apenas que chamá-la dentro da minha entidade usando o comportamento estático da minha Repository e ela que iria fazer o serviço sujo, apenas me retornando - ou não - algo no fim.

Não. Minha sugestão é que você esqueça isso de colocar DAO (tentando sair dos nomes de DDD já que não estamos usando DDD) dentro do objeto e faça algo como isso:

E este código é seu Façade, que é um Service Layer neste caso.

Note que com técnicas e tecnologias mais avançadas que JDBC básico você conseue eliminar algumas partes do exemplo acima.

This message was edited 1 time. Last update was at 07/10/2008 19:51:25

pcalcado wrote:Não.

Caracas ! Ou esse pattern é muito simples e eu tô complicando ou talvez tenha que reconsiderar ir vender dog na esquina =/

pcalcado wrote:Minha sugestão é que você esqueça isso de colocar DAO (tentando sair dos nomes de DDD já que não estamos usando DDD) dentro do objeto

aaah! Pera lá. Então esse Domain-Driven Design nada mais é do que essa sopa de nomes para patterns, principios e conceitos relacionados à OO ?

pcalcado wrote:E este código é seu Façade, que é um Service Layer neste caso.

Entendi. Nesse caso seria o básico do básico. Um objeto que comunica com JDBC para persistir e que retorna um ArrayList com os valores pesquisados e lança umas Exceptions em caso de problemas.

pcalcado wrote:(..)Service Layer(..)

Como eu posso diferenciar uma façade que também exerce função de Service Layer de uma façade que é apenas uma façade ?

Aproveitando que você citou a classe GerenciadorUsuarios: é sempre preferível eu ter um objeto que manipula as entidades à que elas mesmas "se auto-manipularem", correto ? Ou seja, antes eu ter um GerenciadorUsuarios para CRUD à ter os comportamentos de persistência dentro da minha classe Usuario, por exemplo, certo ?

Abraços !

hlegius wrote:
Caracas ! Ou esse pattern é muito simples e eu tô complicando ou talvez tenha que reconsiderar ir vender dog na esquina =/

Acho que eh que voc^e est'a tentando aplicar uma solucao (pattern) sem entender o problema.

hlegius wrote:
aaah! Pera lá. Então esse Domain-Driven Design nada mais é do que essa sopa de nomes para patterns, principios e conceitos relacionados à OO ?

Este post, que eu ja linkei antes, tem uma visao sobre o assunto: http://fragmental.tw/2008/09/23/object-oriented-design-which-how-and-what/

hlegius wrote:

pcalcado wrote:E este código é seu Façade, que é um Service Layer neste caso.

Entendi. Nesse caso seria o básico do básico. Um objeto que comunica com JDBC para persistir e que retorna um ArrayList com os valores pesquisados e lança umas Exceptions em caso de problemas.

nao sei se eu entendi esta frase.

hlegius wrote:

pcalcado wrote:(..)Service Layer(..)

Como eu posso diferenciar uma façade que também exerce função de Service Layer de uma façade que é apenas uma façade ?

Uma Facade pode ser como voce implementa uma service layer. Outra forma, por exemplo, eh atraves de Commands.

hlegius wrote:
Aproveitando que você citou a classe GerenciadorUsuarios: é sempre preferível eu ter um objeto que manipula as entidades à que elas mesmas "se auto-manipularem", correto ? Ou seja, antes eu ter um GerenciadorUsuarios para CRUD à ter os comportamentos de persistência dentro da minha classe Usuario, por exemplo, certo ?

A classe ehe chamada GerenciadorXyz no exemplo porque eu nao conheco seu dominio. O importante no exemplo eh que o ' gerenciador' nao executa nenhuma regra de negocio, ele apenas executa o fluxo tira-objecto-do-banco->chama-metodo-de-negocio-no-objeto->coloca-no-banco-o-resultado-da-computacao.

Opa!

pcalcado wrote:Acho que eh que voc^e est'a tentando aplicar uma solucao (pattern) sem entender o problema.

Na verdade estou tentando entender a solução que o Repository podem vim a ajudar a resolver. Talvez por não conhecê-la direito eu esteja direcionando de forma errada minhas perguntas/afirmações sobre. Acho que é esse o problema =/ Talvez até não tenha sentido nenhum usar Repository para um objeto Pessoa (como coloquei no exemplo lá no começo), mas realmente estou tentando entender o básico dela: o que é, para que serve como posso aplicá-la.

pcalcado wrote:Este post, que eu ja linkei antes, tem uma visao sobre o assunto: http://fragmental.tw/2008/09/23/object-oriented-design-which-how-and-what/

Verdade, eu cheguei a ler mas por cima. Li agora com mais calma e pude entender mais sobre o DDD.

(..)Using Domain-Driven Design the model expressed in software is the model that the business understands.(..)

Talvez seja esse o motivo que esteja recomendando a mim que esqueça os DDD por hora, não ?

hlegius wrote:Entendi. Nesse caso seria o básico do básico. Um objeto que comunica com JDBC para persistir e que retorna um ArrayList com os valores pesquisados e lança umas Exceptions em caso de problemas.

pcalcado wrote:nao sei se eu entendi esta frase.

Então, estava tentando dizer que o exemplo que você passou seria algo bem simples e sem preocupações com Repository, camada de persistência bem abstraída e etc.; Apenas um "corredor" entre as entidades e a camada de persistência.

pcalcado wrote:A classe ehe chamada GerenciadorXyz no exemplo porque eu nao conheco seu dominio. O importante no exemplo eh que o ' gerenciador' nao executa nenhuma regra de negocio, ele apenas executa o fluxo tira-objecto-do-banco->chama-metodo-de-negocio-no-objeto->coloca-no-banco-o-resultado-da-computacao.

Certo !

Shoes, obrigado mesmo pela ajuda e paciência !

Abraço!

pcalcado wrote:Não. Minha sugestão é que você esqueça isso de colocar DAO (tentando sair dos nomes de DDD já que não estamos usando DDD) dentro do objeto e faça algo como isso:

class GerenciadorUsuarios{ pubic void adicionaUsuario(String login, String senha, String nomeGrupo){ Usuario u = new Usuario(login, senha); Grupo g = daoGrupos.buscaPorNome(nomeGrupo); g.adiciona(u); daoUsuario.salva(u); daoGrupo.salva(g); } }

E este código é seu Façade, que é um Service Layer neste caso.

Phillip, tenho três dúvidas a respeito da sua sugestão:

1) O método adicionaUsuario() recebe apenas dois parâmetros. Qual seria a forma ideal de proceder quando há 15, 20 parâmetros ou mais? Um usuário do GUJ me perguntou isso um tempo desses, e eu sugeri a ele duas coisas: utilizar um Map<String, String> com os nomes dos parâmetros e seus conteúdos, ou projetar uma DSL interna.

2) Voltando a DDD só um pouquinho ( e sem querer focar exclusivamente nos padrões mas já focando

), ao invés de chamar o DAO eu poderia, por exemplo, injetar o repositório direto nesse Façade aí né? Ou o uso do repositório é exclusivo da camada de negócios?

3) O Façade acima compõe a camada de aplicação certo? Seria ele, conceitualmente falando, o mesmo Service de que Eric Evans trata no livro dele?

Abraços.

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