É necessário um Repository Pattern quando estiver trabalhando com um ORM como o Entity Framework?

[Acaz Souza]

Lá vem eu novamente, hehe

Estive dando umas pesquisadas e achei essas duas questões no
StackOverflow:

Do we need to use the Repository pattern when working in ASP.NET MVC
with ORM solutions?
http://stackoverflow.com/questions/4724345/do-we-need-to-use-the-repository-pattern-when-working-in-asp-net-mvc-with-orm-sol

Generic Repository With EF 4.1 what is the point
http://stackoverflow.com/questions/5625746/generic-repository-with-ef-4-1-what-is-the-point

Isto levantou a questão de que um ORM como o Entity Framework já tem o
repository pattern:
"DbContext is implementation of unit of work pattern and IDbSet is
implementation of repository pattern."

E o uso de uma outra abstração do ORM é alegado pra se algum dia você
quiser trocar o ORM, mas quanto isso acontece na realidade? Existe
outros benefícios: In the same time wrapping EF code can keep your
code better organized and following Separation of concern rule. For me
this can be the only real advantage of repository and unit of work but
you have to understand that following this rule with EF will maybe
make your code better maintainable and better readable but in the
initial effort to create your application will be much higher and for
smaller applications this can be unnecessary complexity.

E está nova abstração do ORM deixa seu trabalho com EF muito mais
difícil, porque por padrão o ORM já tem várias features que se você
abstrair ele você não vai usar essas features e se precisar usar, vai
ter que implementar.

Isso é mais um assunto pra discussão do que uma questão, onde por moda
de tanto que se fala em Repository Pattern o pessoal querer
implementar isso em todo lugar, deixando de evitar o YAGNI.

Vocês concordam?

[Daniel Moreira Yokoyama]

Você não usa testes né?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

--
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

[Juan Lopes]

Acaz, o Ayende tem uma opinião parecida com a sua:

http://ayende.com/blog/3955/repository-is-the-new-singleton

2011/5/25 Daniel Moreira Yokoyama <moreira....@gmail.com>

--

Kind Regards,

juanplopes@twitter

juanplopes@github

[Ricardo Borges]

Essa é uma questão interessante, recomendo a leitura:

http://ayende.com/blog/3955/repository-is-the-new-singleton

--
if (!SolutionRepository.ExistsFor(problem)) throw new DontWorryException(); else throw new DontWorryAlsoException();
  
R|<4r|)0

[Daniel Moreira Yokoyama]

Pra mim, Repositórios tem várias utilidades:

1. Contextualiza o uso do meu acesso para atender requisitos de negócio. Por exemplo: ClientesInadimplentes.ObterTodos(); ou Clientes.ObterInadimplentes();

2. Mockar o repositório é mais fácil que mockar o ORM... muito embora, mockar está caindo em desuso...

O problema é que, mal aprendem repository pattern, já tem gente que quer criar repositório genérico e talz...

Isto leva para uma direção bem oposta ao que entendo ser a verdadeira utilidade do repositório (que é atender requisitos de negócio).

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

Em 25 de maio de 2011 11:21, Daniel Moreira Yokoyama <moreira....@gmail.com> escreveu:

[Acaz Souza Pereira]

Isto Daniel.

Mockar está caindo em desuso? Por quê?

--
www.twitter.com/acazsouza

www.acazsouza.com

[Ricardo Borges]

Juan, você tem os links já na mão ai né? Foi mais rápido alguns segundos, rs

[Daniel Moreira Yokoyama]

Por que você resolve isto criando ambientes integrados no ambiente do desenvolvimento, fazendo sandboxing...

Mas eu não estou tão por dentro assim disso, sandboxing é algo fascinante, mas pra mim ainda é um segredo... tentei ver isto ser discutido na outra thread, mas não rolou. Qualquer dia desses eu alugo o Juan pra bater um papo a respeito.

De qualquer forma, o lance de mocks é coisa que vi em algum lugar... Stop using Mocks ou coisa do tipo... e imagino que seja por conta desse tipo de coisa.

Mas eu ainda uso mocks... 

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Juan Lopes]

Repositório não é ruim. Mocks não são ruins. Ruim é o dogmatismo. Você não tem que usar nenhum deles, você simplesmente pode usar. Você deve usar aquilo que fizer mais sentido em cada caso.

2011/5/25 Acaz Souza Pereira <acaz...@gmail.com>

--

Kind Regards,

juanplopes@twitter

juanplopes@github

[Daniel Moreira Yokoyama]

Boa Juan... não poderia ter encontrado melhor orientação.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Acaz Souza Pereira]

Mas o DDD prega o uso do Repositoy Pattern? Ou estou enganado?

[Pedro Reys]

Qual a definição de um repositório?

- Pedro Reys

[Denis Ferrari]

Acaz,

Repositórios não são um fim, mas sim um meio. Realmente, trocar o ORM não é uma coisa que fazemos toda segunda-feira, mas deixar o domínio independente de tecnologias é uma boa prática, e o Pattern repositório é um dos meios de se conseguir isso.

Abraços!

Denis Ferrari - "Faça pouco, faça sempre e faça direito"
www.denisferrari.com

Já conhece o #HeroCast?

http://www.heroisdati.com/tags/herocast/

Blogs

www.heroisdati.com

www.minhacarreira.com

2011/5/25 Acaz Souza <acaz...@gmail.com>

[Waldyr Felix - Gmail]

Ok Denis concordo com vc.

 

Mas já que o EF 4.1 já implementa um repositorio no IDbSet e um UnitOfWork ObjectContext nosso repositório seria um "wrapper" disso tudo, ou seja, tá mais pra um Adapter do que pra um Repository.

 

Não é isso?

 

[]s

--
  Waldyr Felix
  http://waldyrfelix.net/blog | @waldyrfelix

[Rafael Ponte]

Não é que mocks estão em desuso, muito pelo contrário. A questão é que para testar a camada de persistência os testes de integração funcionam funcionam muito melhor, além do que, mockar a API do (N)Hibernate quando as operações fogem do trivial não é nada divertido.

2011/5/25 Daniel Moreira Yokoyama <moreira....@gmail.com>

Por que você resolve isto criando ambientes integrados no ambiente do desenvolvimento, fazendo sandboxing...

--
Rafael Ponte
http://www.rponte.com.br

[Denis Ferrari]

Isso para mim é irrelevante. A tecnologia serve ao projeto, não o contrário. O EF facilitar a construção é um bônus, que reduz a complexidade do projeto e praticamente automatiza a construção dos repositórios, mas isso não muda o pattern em si que continua exercendo a mesma função.

Abraços!

Denis Ferrari - "Faça pouco, faça sempre e faça direito"
www.denisferrari.com

Já conhece o #HeroCast?

http://www.heroisdati.com/tags/herocast/

Blogs

www.heroisdati.com

www.minhacarreira.com

2011/5/25 Waldyr Felix - Gmail <waldy...@gmail.com>

[Rafael Ponte]

Do ponto de vista de design de software sim, mas na prática em si não é tão simples assim, o custo dessa abstração é bem alto!

A partir do momento que você isola demais o seu modelo de domínio do framework de persistência você pode perder o que de melhor o seu framework ORM pode te fornecer, normalmente somente para facilitar a substituição da camada de persistência de toda a app num talvez futuro distante.

Como o próprio Eric Evans comenta no seu livro: 

"In general, don't fight your frameworks. Seek ways to keep the fundamentals of domain-driven design and let go of the specifics when the framework is antagonistic. Look for affinities between the concepts of domain-driven design and the concepts in the framework."

2011/5/25 Denis Ferrari <denis....@gmail.com>

[Denis Ferrari]

Rafael,

Eu realmente não luto contra os frameworks, até mesmo pq sem eles eu não entregaria software rápido. Minha diretriz é organizar o projeto botando cada coisa em seu lugar e tentar isolar o domínio.

Até hoje não perdi nada que um framework me fornecia trabalhando dessa maneira. Tem funcionado bem pra mim. 

Abraços!

Denis Ferrari - "Faça pouco, faça sempre e faça direito"
www.denisferrari.com

Já conhece o #HeroCast?

http://www.heroisdati.com/tags/herocast/

Blogs

www.heroisdati.com

www.minhacarreira.com

2011/5/25 Rafael Ponte <rpo...@gmail.com>

[Acaz Souza Pereira]

Rafael, o repository pattern pelo que conheço não é somente pra facilitar a troca da camada de persistência.
Ele tem outras vantagens:

Facilita o uso de testes.
Separation of concern
Deixa as coisas mais simples, ficando mais fácil de ler.
Deixa a manutenção melhor
Não deixa código de framework espalhado pela aplicação.

Mas claro para aplicações pequenas é uma complexidade desnecessária.

www.twitter.com/acazsouza

www.acazsouza.com

[Rafael Ponte]

Acaz,

Eu não disse o contrário, assim como também não disse para não utiliza-lo. O ponto no último e-mail foi outro! :-)

2011/5/25 Acaz Souza Pereira <acaz...@gmail.com>

Rafael, o repository pattern pelo que conheço não é somente pra facilitar a troca da camada de persistência.

[Victor Arias]

Tenho essa duvida faz algum tempo. É realmente uma boa ideia utilizar a repository pattern junto com um ORM como o EF ou o NH?

Se por um lado é mais fácil testar (e outras coisas mais), a abstração pode nos trazer problemas como o clássico SELECT N + 1.

[Juan Lopes]

Pois é. Também tenho me perguntado isso ultimamente. Não sei se gosto da abstração completa que um ORM me trás. Obviamente gosto da abstração das queries (ainda com ressalvas). Mas não sei se o resto me agrada.

Ainda estou pensando sobre o assunto.

2011/5/25 Victor Arias <aria...@gmail.com>

Tenho essa duvida faz algum tempo. É realmente uma boa ideia utilizar a repository pattern junto com um ORM como o EF ou o NH?

Se por um lado é mais fácil testar (e outras coisas mais), a abstração pode nos trazer problemas como o clássico SELECT N + 1.

--

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

--

Kind Regards,

juanplopes@twitter

juanplopes@github

[Fernando Souza]

Eu já tentei utilizar o padrão Repository sem ORM e só me lasquei...
Você não tem Lazy-Load. Você imita o efeito com "gambiarras";
Os agreggates acabam ficando meio "violados";
Pra tentar contornar estes desafios, é capaz que você acabe criando um
ORM só pra aquela solução...
Pra evitar o Select N+1, só disciplina mesmo... Nas vezes que
aconteceu comigo, eu tinha feito merda no modelo e/ou mapeamento.

[Vinicius Quaiato]

Pq uma complexidade desnecessaria? Basicamente vc terauma dezena a mais de linhas encapsulando sua persistencia, nao eh tao complexo.

E os beneficios que vc citou como sendo do pattern saona vdd de qlqr bom design oo

Att,

Vinicius Quaiato

Enviado via iPhone