.NET Domain-Driven Design with C#: Problem-Design-Solution - RepositoryFactory

[Abner das Dores]

Fala pessoal!

Acredito que muitos de vocês conheçam o livro ".NET Domain-Driven Design with C#: Problem-Design-Solution".

Existe um projeto no codeplex com o código fonte do estudo de caso do livro, que pode ser visto no seguinte link: http://dddpds.codeplex.com/

Analisando os padrões adotados pelo autor na implementação, o que me chamou a atenção foi o fato dele usar uma espécie de Service Locator para resolver as instâncias dos repositórios utilizados pelo domínio, que pode ser visto na classe RepositoryFactory, na camada de Infraestrutura do projeto.

Eu achei interessante a abordagem, pois te dá o controle total sobre as instâncias que serão utilizadas pela sua aplicação através de modificações nos arquivos de configuração e não te prende a nenhum framework de terceiros para fazer uma injeção de dependência. 

Não vejo nenhum efeito colateral em implementar algo assim, mas gostaria de saber a opinião de vocês sobre esse tipo de abordagem e os prós e contras com relação a utilizar algum framework de injeção de dependência.

Abraços!

--

Abner das Dores

[Alexsandro]

Este? http://dddpds.codeplex.com/SourceControl/changeset/view/69709#16106

[Abner das Dores]

Esse mesmo Alexsandro!

Na utilização seria algo da seguinte forma:

ProjectService.projectRepository = 

              RepositoryFactory.GetRepository<IProjectRepository,Project>(ProjectService.unitOfWork);

--
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
 
 

[Rodrigo Silva de Andrade]

Eu acho que tem abstração demais

2013/1/24 Juliano Alves <von.j...@gmail.com>

Um framework que existe já faz algum tempo foi feito por pessoas dedicadas somente à esse objetivo. Há muitas vantagens em usá-los, ainda mais quando são open-source. Eles já foram testados à exaustão, são estáveis, geralmente possuem uma boa documentação e às vezes são melhorados através de contribuições da comunidade.

São poucas as chances de se fazer um trabalho melhor do que as pessoas que se dedicaram às ferramentas existentes. Eu não vejo porque não usar uma ferramenta pronta.

Em quinta-feira, 24 de janeiro de 2013 13h27min25s UTC-2, Abner das Dores escreveu:

--

[Mário Meyrelles]

Muito lindo o código. Mas parece que criaram uma dificuldade pra vender facilidade. Não me vejo utilizando algo assim em meu atual estágio de ignorância rs...

2013/1/24 Rodrigo Silva de Andrade <dang...@gmail.com>

[Alexsandro]

Acho que ele esta mais preocupado com a dependencia extra no projeto ja que poderia evitar, acho que foi isto que ele questionava a vantagem aqui.


Mas sua opnião de usar algo ja existem tambem é bem relevante e concordo. Eu acho muito importante quando tem um pessoal que mantem um lib open-source que a faz evoluir a cada dia mais.

Eu particulamente uso libs feito por terceiros se este for exclusivo para resolver o problema proposto, quando promete coisas alem, eu ja não gosto muito.

Em quinta-feira, 24 de janeiro de 2013 15h53min08s UTC-2, Juliano Alves escreveu:

Um framework que existe já faz algum tempo foi feito por pessoas dedicadas somente à esse objetivo. Há muitas vantagens em usá-los, ainda mais quando são open-source. Eles já foram testados à exaustão, são estáveis, geralmente possuem uma boa documentação e às vezes são melhorados através de contribuições da comunidade.

São poucas as chances de se fazer um trabalho melhor do que as pessoas que se dedicaram às ferramentas existentes. Eu não vejo porque não usar uma ferramenta pronta.

Em quinta-feira, 24 de janeiro de 2013 13h27min25s UTC-2, Abner das Dores escreveu:

[Abner das Dores]

Concordo que o nível de abstração é alto demais. E concordo também que frameworks especialistas estão ai testados e aprovados pela comunidade, o garante bastante segurança na sua utilização. Nesse caso poderia resolver o mesmo problema com o Ninject por exemplo.

Agora, pensando em DDD, seria purismo demais dizer que um framework tipo o Ninject pode poluir o meu domínio pelo fato de ter que usar as suas Annotations?

--

[Marcus Alexandre Silva]

Sinto o mesmo desconforto....

[Abner das Dores]

Ninguém tem mais nada a acrescentar à discussão?

[Robson Castilho]

Olá, Abner

Não seria purismo não. É o mais sensato que seu domínio não conheça o Ninject. Deixa isso para uma camada mais externa. No domínio, normalmente uso constructor-injection.

My opinion.

[]s

[Alexandre Santos Costa]

Concordo com o amigo. O dominio deve ser o mais agnóstico de tecnologia possível e hoje todos os bons frameworks de TI implementam a injeção por construtor.

[Abner das Dores]

Robson, valeu pela resposta.

Realmente, não tinha parado para analisar por esse ponto. Eu posso usar constructor injection no domínio e resolver a dependência com um framework na camada de aplicação ou de apresentação.

Acho que isso resolve o problema sem "sujar" o domínio...