Mais uma dúvida sobre Entites X Repositories dentro de DDD

[Alessandro_Lazarotti]

Quem mascara o acesso a uma fonte de dados é o repositório, se você está usando um DAO dentro do repositório, é uma opção de implementação sua (…) Não vejo porque misturar DAOs e repositórios, quando ambos fazem a mesma coisa, eles só tem “idéias” diferentes.

Sim, o que mostrei é UMA implementação… por isso coloquei o ‘uma’ entre aspas no post. Ja tive muito ganho nesta separação centralizando o acesso em único ponto (quando por exemplo mudei fecthMode de todo o projeto, e tive que controlar todos os pontos de flush da persistência). Se não tivesse canalizado a persistência, teria que refatorar todos meus repositórios. Isso é um exemplo do pq dividir bem as responsabilidades de DAOs e Repositorios (isso é opinião, em nenhum momento quero afirmar que isso tem que ser assim).

[Mauricio_Linhares]

Sim, o que mostrei é UMA implementação… por isso coloquei o ‘uma’ entre aspas no post. Ja tive muito ganho nesta separação centralizando o acesso em único ponto (quando por exemplo mudei fecthMode de todo o projeto, e tive que controlar todos os pontos de flush da persistência). Se não tivesse canalizado a persistência, teria que refatorar todos meus repositórios. Isso é um exemplo do pq dividir bem as responsabilidades de DAOs e Repositorios (isso é opinião, em nenhum momento quero afirmar que isso tem que ser assim).

Uma dúvida nadas haver agora, você faz flush manualmente no DAO?

[ronildobraga]

[quote=Lezinho][code]
public class RepositorioAlunoImpl implements RepositorioAluno{

@In
private DataAcessObject dao;

 public void adiciona(Aluno aluno){
       
     //pode realizar alguma rotina comum 
     //ao objeto 'aluno' antes de persistir seu estado
     ....           

        dao.persiste(aluno);
  }

}
[/code][/quote]
Estou acompanhando a conversa de vocês desde o inicio, porem fiquei com uma duvida com o código acima.
Como vc fez esta implementação de repository usando a anotação @In ?
Eu estou imaginando que vc tenha 1 interface e 2 classes: RepositorioAluno, RepositorioAlunoImpl, DataAcessObject
Apesar da classe se chamar DataAcessObject creio que ela na verdade deveria se chamar AlunoDAO

Imagino que vc esta injetando(@In) o DAO na sua implementação do Repository do Aluno para não criar uma fábrica, caso seja verdade, vc poderia dar mais detalhes de como vc fez essa injeção ? Como o DAO recebe o EntityManager para persistir a entidade ?

[Alessandro_Lazarotti]

Tem certeza? Porque ele não pode armazenar os dados se pra criar um aluno eu tenho que fazer um “Aluno.new” (em Ruby, por exemplo) ?

Sim. Fazendo isso em Ruby você esta criando um novo objeto do tipo Aluno e não o recuperando. Um tipo cria instâncias do seu tipo, normal… Um repositório não busca necessariamente informações apenas no seu tipo, já que um prática é te-lo apenas para Entities Roots.

A implementação da sua interface para testes vai ser tão falsa quanto os meus métodos estaticos mockados.

Como fazer isso em Java, em uma situação do tipo:

public class ClasseQualquer{
	
	
	// isso aqui é interface, pra testar é tranquilo
	@In RepositorioQualquer repositorioQualquer;

	public void umMetodoQualquer(){

		Object objetoQualquer  = codigoDeNegocio.fazAlgumaCoisa();  
		// abaixo vc teria um metodo equivalente, mas estatico, para recuperacao de dados
  		List objetosDiversos =  repositorioQualquer.buscaInformacoes(objetoQualquer) 
  		for(Object objetoQualquer:objetosDiversos) {
			objetoQualquer.processaAlgo();
 	 	}
	}

}

Você utiliza mock para método estático? Qual framework vc utiliza(é que realmente eu nunca precisei utilizar desta forma).

[Alessandro_Lazarotti]

[quote=Lezinho]Sim, o que mostrei é UMA implementação… por isso coloquei o ‘uma’ entre aspas no post. Ja tive muito ganho nesta separação centralizando o acesso em único ponto (quando por exemplo mudei fecthMode de todo o projeto, e tive que controlar todos os pontos de flush da persistência). Se não tivesse canalizado a persistência, teria que refatorar todos meus repositórios. Isso é um exemplo do pq dividir bem as responsabilidades de DAOs e Repositorios (isso é opinião, em nenhum momento quero afirmar que isso tem que ser assim).

Uma dúvida nadas haver agora, você faz flush manualmente no DAO?[/quote]

Sim, foi necessário Maurício. O projeto utilizava transação otimista, com o flushMode em auto e a transação sendo gerenciada pelo Seam da duração de uma requisição. Contudo, quando se utilizava Ajax e o modelo do faces era atualizado, aquele XMLRequest descarregava no banco a alteração (o que não era o esperado).

[Alessandro_Lazarotti]

[quote=ronildo braga]Estou acompanhando a conversa de vocês desde o inicio, porem fiquei com uma duvida com o código acima.
Como vc fez esta implementação de repository usando a anotação @In ?
Eu estou imaginando que vc tenha 1 interface e 2 classes: RepositorioAluno, RepositorioAlunoImpl, DataAcessObject
Apesar da classe se chamar DataAcessObject creio que ela na verdade deveria se chamar AlunoDAO

Imagino que vc esta injetando(@In) o DAO na sua implementação do Repository do Aluno para não criar uma fábrica, caso seja verdade, vc poderia dar mais detalhes de como vc fez essa injeção ? Como o DAO recebe o EntityManager para persistir a entidade ?[/quote]

A Anoatação @In, é a maneira que o Seam faz DI. No código citado, eu injeto RepositorioAlunoImpl em RepositorioAluno e DataAcessObjectImpl (ou implementações específicas) no dao.

o ‘dao’ de maneira alguma é algo do tipo “AlunoDAO”. Ele contém, por exemplo, o entityManager e métodos de pesquisas não especialistas. Ele faz todo o controle da infra:

Um exemplo de sua interface:

[code]
public interface DataAccessObject {

public abstract void queryUpdate(String queryString);


public abstract List query(String queryString);

public abstract void queryUpdate(String queryString,Map<String, Object> namedParameters);


public abstract List query(String queryString,Map<String, Object> namedParameters);

public abstract void queryUpdate(String queryString, Object[] params);


public abstract List query(String queryString, Object[] params);

public abstract void persist(Object obj);

public Object saveOrUpdate(Object obj);	

public abstract void remove(Object obj);

(…)
} [/code]

… o repositório da a alma para a consulta. Este tipo de implementação me agrada pela flexibilidade que se tem nas camadas.

[Alessandro_Lazarotti]

Ou seja, IMHO repositorios nao devem conter regras de negocio.

Em minha opinião ele tem que ter, afinal de contas ele faz parte do domínio.

[Mauricio_Linhares]

[quote=mauricio linhares]Tem certeza? Porque ele não pode armazenar os dados se pra criar um aluno eu tenho que fazer um “Aluno.new” (em Ruby, por exemplo) ?

Sim. Fazendo isso em Ruby você esta criando um novo objeto do tipo Aluno e não o recuperando. Um tipo cria instâncias do seu tipo, normal… Um repositório não busca necessariamente informações apenas no seu tipo, já que um prática é te-lo apenas para Entities Roots.[/quote]

Opa, um repositório deveria buscar apenas o root, se você precisa de alguma coisa que está na agregação tem que pegar o root e do root acessar o agregado, não?

Você utiliza mock para método estático? Qual framework vc utiliza(é que realmente eu nunca precisei utilizar desta forma).

Esqueça Java homem

Enfim, o que eu estou tentando dizer é que, objeto falso por objeto falso, ambos fazem a mesma coisa, tanto a interface mockada como os métodos estáticos mockados. E eu nunca fiz isso em Java não, mas se fosse fazer eu acho que precisaria de algumas mágicas com o AspectJ.

[cmoscoso]

Se tem valor pro negocio deverá ser implementado no dominio, mas não é requisito de nenhum negocio que seja feito por meio de repositorios.

Mas repositório é domínio … e se ele cuida da recuperação de objetos, não vejo porque não estar nele.

Although REPOSITORIES and FACTORIES do not themselves come from the domain, they have
meaningful roles in the domain design. These constructs complete the MODEL-DRIVEN DESIGN by
giving us accessible handles on the model objects.
Modeling AGGREGATES and adding FACTORIES and REPOSITORIES to the design gives us the ability to
manipulate the model objects systematically and in meaningful units throughout their life cycle.
AGGREGATES mark off the scope within which invariants have to be maintained at every stage of
the life cycle. FACTORIES and REPOSITORIES operate on AGGREGATES, encapsulating the complexity of
specific life cycle transitions.

[cmoscoso]

[quote=Lezinho]

Ou seja, IMHO repositorios nao devem conter regras de negocio.

Em minha opinião ele tem que ter, afinal de contas ele faz parte do domínio.[/quote]

Se lesse meus posts nessa thread direcionados a você perceberia o que estou tentando lhe dizer. Existem certos objetos de dominio que possuem outras responsabilidades (de suporte) que nao a de expressar o modelo de negocio.

[Alessandro_Lazarotti]

[quote=cmoscoso][quote=Lezinho]
Mas repositório é domínio …
[/quote]

Although REPOSITORIES and FACTORIES do not themselves come from the domain, they have
meaningful roles in the domain design. These constructs complete the MODEL-DRIVEN DESIGN by
giving us accessible handles on the model objects.
Modeling AGGREGATES and adding FACTORIES and REPOSITORIES to the design gives us the ability to
manipulate the model objects systematically and in meaningful units throughout their life cycle.
AGGREGATES mark off the scope within which invariants have to be maintained at every stage of
the life cycle. FACTORIES and REPOSITORIES operate on AGGREGATES, encapsulating the complexity of
specific life cycle transitions.

[/quote]
Normalmente em uma modelagem conceitual, você não define factories e repositories. Dado a isso, de fato eles não são criados pelo domínio e sua natureza, embora pertença a ele implícitamente.

A citação diz isso:

“do not themselves come from the domain”

… um cliclo de vida depende dos critérios exigidos pelo domínio.

[Alessandro_Lazarotti]

[quote=mauricio linhares]
Opa, um repositório deveria buscar apenas o root, se você precisa de alguma coisa que está na agregação tem que pegar o root e do root acessar o agregado, não?[/quote]

Imagine um objeto ‘produto’ e outro ‘caracteristica’, onde produto cotem um colecao da entidade fraca chamada caracteristica.

Você precisa apresentar na tela todas as caracteristicas, para poder atribui-la a um produto. Quem faz a consulta retornando todas as entidades fracas “caracteristica” que ira compor um produto?

Esqueça Java homem

Enfim, o que eu estou tentando dizer é que, objeto falso por objeto falso, ambos fazem a mesma coisa, tanto a interface mockada como os métodos estáticos mockados. E eu nunca fiz isso em Java não, mas se fosse fazer eu acho que precisaria de algumas mágicas com o AspectJ.

O exemplo de código que escrevi, o qual debatemos, era Java, não era?

[Mauricio_Linhares]

[quote=Lezinho]Imagine um objeto ‘produto’ e outro ‘caracteristica’, onde produto cotem um colecao da entidade fraca chamada caracteristica.

Você precisa apresentar na tela todas as caracteristicas, para poder atribui-la a um produto. Quem faz a consulta retornando todas as entidades fracas “caracteristica” que ira compor um produto?[/quote]

Bem, não entendi bem o seu exemplo, mas se característica é uma “entidade fraca” ela não deve existir sem um produto e tecnicamente não dá pra chegar nela sem um produto, dá? O produto já vem que vir com as suas características carregadas.

O exemplo de código que escrevi, o qual debatemos, era Java, não era?

Eu estou discutindo conceitos, se você quer discutir a implementação em Java (que eu já repeti diversas vezes que é complicada) é outra história. Estamos falando de coisas diferentes então.

[cmoscoso]

[quote=Lezinho]
Normalmente em uma modelagem conceitual, você não define factories e entities. Dado a isso, de fato eles não são criados pelo domínio e sua natureza, embora pertença a ele implícitamente.

A citação diz isso:

“do not themselves come from the domain”

… um cliclo de vida depende dos critérios exigidos pelo domínio.[/quote]

Onde você disse entities creio que seria repositorios…

Mas mesmo assim nao entendi nada do que você escreveu, muito menos relacionar com regras de negocio em repositorios que era o meu ponto. :?

[Alessandro_Lazarotti]

Bem, não entendi bem o seu exemplo, mas se característica é uma “entidade fraca” ela não deve existir sem um produto e tecnicamente não dá pra chegar nela sem um produto, dá? O produto já vem que vir com as suas características carregadas.

Mas eu estou criando um novo produto e tenho que selecionar características para atribuir a este.

Um produto é composto de características, depois de criado, o que você disse é verdade. Mas primeiro eu preciso criar este novo objeto …

[quote=mauricio linhares]
Eu estou discutindo conceitos, se você quer discutir a implementação em Java (que eu já repeti diversas vezes que é complicada) é outra história. Estamos falando de coisas diferentes então.[/quote]

É, existe uma confusão em nossa conversa. O tempo todo eu tbm disse que se fosse em Ruby, usaria AR sem pestanejar. Quando coloquei o código em java, achei estranho você dizer que não teria problemas para realizar testes no método estático, foi isso.

[Mauricio_Linhares]

[quote=Lezinho]Mas eu estou criando um novo produto e tenho que selecionar características para atribuir a este.

Um produto é composto de características, depois de criado, o que você disse é verdade. Mas primeiro eu preciso criar este novo objeto …[/quote]

Continuo sem entender. As características já existiam no banco de dados antes do produto existir?

[Alessandro_Lazarotti]

[quote=cmoscoso] Onde você disse entities creio que seria repositorios…

Mas mesmo assim nao entendi nada do que você escreveu, muito menos relacionar com regras de negocio em repositorios que era o meu ponto[/quote]

Eita, escrevi errado, já esta editado.
Não entendi o que você não entendeu (fora minha palavra trocada), mas tudo bem.

O que não sei onde não fui claro é que métodos do tipo: buscaRendimentoAprovado faz total parte do negócio, isso não é visível pra você?

[Alessandro_Lazarotti]

[quote=Maurício Linhares][quote=Lezinho]Mas eu estou criando um novo produto e tenho que selecionar características para atribuir a este.

Um produto é composto de características, depois de criado, o que você disse é verdade. Mas primeiro eu preciso criar este novo objeto …[/quote]

Continuo sem entender. As características já existiam no banco de dados antes do produto existir?[/quote]
Sim

[Mauricio_Linhares]

E como é que elas são entidades fracas?

Se elas existem e são buscadas sem o aggregate, deveriam ter um repositório só pra elas.

[cmoscoso]

O que não sei onde não fui claro é que métodos do tipo: buscaRendimentoAprovado faz total parte do negócio, isso não é visível pra você?

Faz parte do negocio ao aderir à UBIQUITOUS LANGUAGE. Mas estou falando de regras de negocio e assinaturas de metodos nao possuem regras de negocio, nem a implementacao de buscaRendimentoAprovado caso este seja um metodo de repositorio.

editado: concluindo, repositorios vivem no dominio, se expressam em termos da ubiquitous language, mas nao devem conter regras de negocio em sua implementacao.