A classe é inútil no sentido da sua definição estática (métodos estáticos), os comportamentos da entidade estão em seus métodos de instância.
Não acho, na verdade eu vejo isso como sendo algo bem incomum, dos diversos projetos que eu participei até hoje usando AR foi o único caso que isso realmente teve que ser feito, principalmente porque havia muita coisa de análise e mineração de dados, então eram coisas que não cabiam mesmo ali.
Galera mais uma dúvida surgiu, na opinião de vocês, existe mesmo sentido em injetar o Repositório, quando necessário em Entities sendo que estes estão intrissicamente ligados em um determinado problema?
Qual seria o sentido desse nível de separação? Algum artigo bacana que justifique os ganhos dessa separação?
Valeu.
[quote=luizaso]Galera mais uma dúvida surgiu, na opinião de vocês, existe mesmo sentido em injetar o Repositório, quando necessário em Entities sendo que estes estão intrissicamente ligados em um determinado problema?
Qual seria o sentido desse nível de separação? Algum artigo bacana que justifique os ganhos dessa separação?
Valeu.[/quote]
Rapaz, o problema é que é muito complicado de se injetar um repositório em uma entidade, especialmente se a entidade ainda não foi salva ou quando ela é na verdade uma entidade relacionada a a entidade principal que foi carregada do seu repositório.
Normalmente quando você precisa de alguma coisa assim, é mais fácil recorrer a um serviço que ligue o(s) repositório(s) a(s) entidade(s).
Bacana Maurício, no seu comentário você diz…
Ou seja, se eu chegar a conclusão que não há a necessidade de utilizar injeção de dependência para utilizar meu repositório em minha entidade, não estarei quebrando uma regra de DDD, certo?
Não vejo problema nenhum nisso.
[quote=Mauricio Linhares]
A classe é inútil no sentido da sua definição estática (métodos estáticos), os comportamentos da entidade estão em seus métodos de instância. [/quote]
Pois é, contra isso não tem mesmo o que eu dizer, é uma opção de design com seus prós e contras.
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();[quote=luizaso]Bacana Maurício, no seu comentário você diz…
Ou seja, se eu chegar a conclusão que não há a necessidade de utilizar injeção de dependência para utilizar meu repositório em minha entidade, não estarei quebrando uma regra de DDD, certo?[/quote]
http://www.guj.com.br/posts/list/84469.java
… pode lhe ajudar em alguma coisa.
[quote=Maurício Linhares][quote=luizaso]Galera mais uma dúvida surgiu, na opinião de vocês, existe mesmo sentido em injetar o Repositório, quando necessário em Entities sendo que estes estão intrissicamente ligados em um determinado problema?
Qual seria o sentido desse nível de separação? Algum artigo bacana que justifique os ganhos dessa separação?
Valeu.[/quote]
Rapaz, o problema é que é muito complicado de se injetar um repositório em uma entidade, especialmente se a entidade ainda não foi salva ou quando ela é na verdade uma entidade relacionada a a entidade principal que foi carregada do seu repositório.
Normalmente quando você precisa de alguma coisa assim, é mais fácil recorrer a um serviço que ligue o(s) repositório(s) a(s) entidade(s).[/quote]
Uma factory pode ajudar neste sentido.
[]s
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.
Em relação a isso, o como implementar é até tranquilo, no caso como meu projeto é em .NET, utilizo o Castle Windsor para implementar IoC / DI.
Agora a grande motivação para se injetar um Repositório em uma Entity, seria Testes Unitários, estou certo?
Abraços.
[quote=Lezinho]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.
[code]
//uma opcao
List<Aluno> alunosEmDebito = Aluno.obtemAlunosEmDebito();
//acho essa mais legivel
List<Aluno> alunosEmDebito = repositorioAluno.obtemAlunosEmDebito();
[/code][/quote]
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.
Aspecto nele :twisted:
Não vejo relacionamento entre uma coisa e outra.
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.[/quote]
Oi Maurício,
Penso na factory criando a entidade e injetando o repositório.
[]s
Vixe, que complicação.
Serviços fazem o trabalho de forma bem mais simples.
Só complementando, vai da cabeça e do martelo de quem está implementando, fazer AR em Java não é lá muito simples não.
Vixe, que complicação.
Serviços fazem o trabalho de forma bem mais simples.[/quote]
hehehe,… ai vai depender do contexto. A factory é uma das opções, IMO bem simples de compreender. 
[]s
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,
infelizmente aspéctos não são tão realidade no mundo .net quanto são em java.
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!!!