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

Lezinho wrote:Eu sinceramente acredito que se faz uma melhor coesão sem os métodos estáticos na classe da entidade. Opto por um repositório separado, abstraído por uma interface, que me facilite entre outras coisas a execução de testes, além de ajudar na legibilidade.
//uma opcao List<Aluno> alunosEmDebito = Aluno.obtemAlunosEmDebito(); //acho essa mais legivel List<Aluno> alunosEmDebito = repositorioAluno.obtemAlunosEmDebito();

Eu já acho a primeira bem mais legível, além de conter menos símbolos a serem lembrados, em vez de eu saber que tem uma interface de repositório e uma implementação, eu tenho apenas a classe que eu estou buscando.

Eu vejo que repositórios tem seu uso em sistemas que precisam ser independentes de bancos de dados ou que precisam suportar diversos bancos de dados com instruções ou modos de trabalho diferentes, fora isso eu não consigo ver vantagem em utilizá-los no dia a dia.

Mas é uma questão de ponto de vista, basicamente os dois conseguem resolver o problema ao qual se propoem, escolher um ou o outro vai da cabeça de quem estiver desenvolvendo a solução.

This message was edited 1 time. Last update was at 24/03/2008 16:28:14

laercio wrote: Uma factory pode ajudar neste sentido.

Aspecto nele

luizaso wrote:Agora a grande motivação para se injetar um Repositório em uma Entity, seria Testes Unitários, estou certo?

Não vejo relacionamento entre uma coisa e outra.

Maurício Linhares wrote:

Laércio Queiroz wrote:Uma factory pode ajudar neste sentido.

Uma factory que cria o repositório? E quem injeta a factory na entidade?

Aí ficamos com a história do ovo e da galinha.

Oi Maurício,

Penso na factory criando a entidade e injetando o repositório.

[]s

Laércio Queiroz wrote:Penso na factory criando a entidade e injetando o repositório.

Vixe, que complicação.

Serviços fazem o trabalho de forma bem mais simples.

Maurício Linhares wrote:Mas é uma questão de ponto de vista, basicamente os dois conseguem resolver o problema ao qual se propoem, escolher um ou o outro vai da cabeça de quem estiver desenvolvendo a solução.

Só complementando, vai da cabeça e do martelo de quem está implementando, fazer AR em Java não é lá muito simples não.

Maurício Linhares wrote:

Laércio Queiroz wrote:Penso na factory criando a entidade e injetando o repositório.

Vixe, que complicação.

Serviços fazem o trabalho de forma bem mais simples.

hehehe,... ai vai depender do contexto. A factory é uma das opções, *IMO* bem simples de compreender.

[]s

This message was edited 1 time. Last update was at 24/03/2008 16:51:51

Maurício,

o que quiz dizer, é que quando você acessa um repositório por uma interface, separando sua implementação e injetando essa de alguma forma, seja factory ou aspéctos, você tem a vantagem de depois poder criar um repositório fake quando for fazer os seus testes.

Claro que você sempre pode usar Mocks, mas se já tiver um repositório fake implementado, acaba que consegue ter a vantagem de reaproveita-lo e diminuir a quantidade de códigos no momento de criar os testes unitários.

Bom na verdade eu ainda estou procurando a real vantagem de se utilizar DI, para injetar meus repositórios em minhas entidades, essa vantagem ainda não ficou clara pra mim.

Leozinho wrote: Aspecto nele

Leozinho,

infelizmente aspéctos não são tão realidade no mundo .net quanto são em java.

luizaso wrote:....

Mas é exatamente por isso que eu não entendi, isso é a vantagem básica se se usar DI em qualquer coisa, não é específica desse caso.

De qualquer forma, eu acho complicado injetar repositórios em entidades, serviços são mais simples de se utilizar e manter.

Maurício, eu citei um exemplo desta vantagem de se usar DI, claro que existem outros muitos, só queria alguns de referência para apoiar minha decisão arquitetural em minha aplicação.

Outra dúvida, desculpe a minha ignorância, mas o que são esses Serviços citados por você como vantagem sobre o uso de DI.

Valeu!!!

Maurício Linhares wrote:

luizaso wrote:....

Mas é exatamente por isso que eu não entendi, isso é a vantagem básica se se usar DI em qualquer coisa, não é específica desse caso.

De qualquer forma, eu acho complicado injetar repositórios em entidades, serviços são mais simples de se utilizar e manter.

Se o servico fizer sentido no domínio eu concordo contigo. Mas nos casos onde a entidade é quem deve fornecer as informações e precisa do repositório para isso, não vejo muito sentindo em implementar esta operação em outro lugar e tirar essa responsabilidade da entidade.

[]s

This message was edited 1 time. Last update was at 24/03/2008 17:10:54

Maurício e outros, por favor, ignorem a minha pergunta sobre serviços acima, desculpem, foi falta de atenção.

This message was edited 1 time. Last update was at 24/03/2008 20:01:55

Maurício Linhares wrote: Eu vejo que repositórios tem seu uso em sistemas que precisam ser independentes de bancos de dados ou que precisam suportar diversos bancos de dados com instruções ou modos de trabalho diferentes, fora isso eu não consigo ver vantagem em utilizá-los no dia a dia.

Quem lhe dá independência de banco de dados é o DAO, não o Repository.

Pra mim a função do repositório é mesmo uma função de domínio.
Aproveitando meu exemplo anterior, veja o código abaixo:

A linguagem é clara e distingue bem os deveres do repositorio e da entidade. Utilizando métodos estáticos na entidade para agir como repositório, essa divisao de responsabilidade não ficaria tão clara (Aluno.obtemAlunosEmDebito()), além de dificultar os testes unitários.

Maurício Linhares wrote:Só complementando, vai da cabeça e do martelo de quem está implementando, fazer AR em Java não é lá muito simples não.

Isso é verdade. Como já disse, se o sistema esta sendo desenvolvido em RoR, seria besteira não utilizar AR (ignorar uma funcionalidade que esta alí de graça por "particularidades de design", não parece ser uma escolha muito sensata). Já fazer isso em Java, é tão insensato o quanto.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Lezinho wrote:Um repositório, diferente de uma factory, tem sentido real. É fatídico que as informações do negócio devem ser armazendas em algum repositório de dados, isso faz parte do core business, assim como a recuperação destes objetos. Este lugar de armazenamento é o repositório... o negócio tem conhecimento disso.

A Factory é um simples artifício de criação, irrelevante para o negócio.

Eu sei que o topico nao é sobre factories mas gostaria de esclarecer alguns pontos.

Factories encapsulam a criacao complexa de alguns objetos de dominio. Você pode delegar à factories a reconstituicao de objetos ja persistidos, não é só criacao de novos objetos. E um dominio pode nao precisar armazenar informacoes, assim como nem todo dominio possui agregados complexos que justifiquem factories. Um "sentido real" para cada conceito é relativo, depende de cada caso.

Outra coisa, não faz parte do core business que as informacoes devam ser armazenadas no repositorio de dados. Faz parte sim de algum core business que uma mesma conta bancaria criada agora deve ser acessível posteriormente. Essa existencia atraves de diferentes ciclos de vida é o que define o conceito de entidade.

Factories e repositorios sao utilizados para suportar ciclos de vida dos objetos de dominio, ambos sao irrelevantes para o negocio.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

cmoscoso wrote:Outra coisa, não faz parte do core business que as informacoes devam ser armazenadas no repositorio de dados. Faz parte sim de algum core business que uma mesma conta bancaria criada agora deve ser acessível posteriormente. Essa existencia atraves de diferentes ciclos de vida é o que define o conceito de entidade.

Factories e repositorios sao utilizados para suportar ciclos de vida dos objetos de dominio, ambos sao irrelevantes para o negocio.

É de total relevância para a conta bancária informações sobre o rendimento total de uma determinada poupança em um período. Essa consulta faz parte do negócio e tem valor p/ o cliente, inclusive essa é a linguagem natural que ele usa.
Como ele é buscado na infra, não interessa, um DAO ou outro meio me retorna isso, mas essa funcionalidade de extração da informação é de grande importância. A assinatura deste método de busca de dados, tem que ser ubiquitous e conhecida pelo especialista do domínio e pela equipe de desenvolvimento.

A relevância da factory é mais branda. Um repository pode utilizar uma factory para montar uma informação, mas isso não é lá tão transparente para o negócio, mesmo sendo necessário para o domínio.

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