Duvida Modelo Anêmico e Modelo Rico
311 views
Skip to first unread message
Rene Felix Correa
Jun 11, 2012, 9:13:29 PM6/11/12
to dotnetar...@googlegroups.com
Bom dia Pessoal,
Sempre trabalhei em projetos aonde aplicava uma arquitetura no Modelo Anemicos, e estou iniciando um projeto para estudo e estou aplicando modelo Rico, pelo menos tentando, e me surgiram algumas duvidas, seguem as duvidas:
Sempre trabalhei em projetos aonde aplicava uma arquitetura no Modelo Anemicos, e estou iniciando um projeto para estudo e estou aplicando modelo Rico, pelo menos tentando, e me surgiram algumas duvidas, seguem as duvidas:
1) É possivel aplicar Service pattern em uma aplicação com modelo Rico ?
2) Aplicando Repository pattern na aplicação, o repositorio terá a responsabilidade de salvar as entidades, mais aonde eu irei criar o repositorio e encapsulo alguma logica, por exemplo alterar o estado de algumas entidades e salva-las?
3) Injetar ou atribuir um repositorio para uma classe do modelo e dentro dessa classe do modelo executar metodos do repositorio é correto?
Se alguem tiver um projeto de exemplo no git hub aplicando essas praticas ou praticas melhores, por favor me mandem
Muito Obrigado.
Denis Ferrari
Jun 12, 2012, 7:44:21 AM6/12/12
to dotnetar...@googlegroups.com
Bom dia Rene,
Tempos atrás houve um podcast sobre o tema aqui no grupo, se ainda não ouviu, recomendo:
Antes de mais nada, é ideal que você se foque menos nos patterns e mais na Linguagem Ubíqua e na Orientação a Objetos em si. Essas duas coisas serão o seu norte, na hora de modelar o seu domínio. Seguem alguns links de referência:
Agora sobre suas perguntas:
1) É possivel aplicar Service pattern em uma aplicação com modelo Rico ?
Sim, mas geralmente em escala bem menor do que em um modelo anêmico.
2) Aplicando Repository pattern na aplicação, o repositório terá a responsabilidade de salvar as entidades, mais aonde eu irei criar o repositorio e encapsulo alguma logica, por exemplo alterar o estado de algumas entidades e salva-las?
É de responsabilidade das próprias classes alterar o seu estado. A sua camada de persistência simplesmente persiste tudo ao final. Repositórios não possuem Update, isso é transparente.
3) Injetar ou atribuir um repositorio para uma classe do modelo e dentro dessa classe do modelo executar metodos do repositorio é correto?
--
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
Felipe Santos
Jun 12, 2012, 7:22:21 PM6/12/12
to .Net Architects
Denis?
De acordo com o mesmo senário citado pelo Rene, a responsabilidade de
CRUDE fica por conta de cada entidade?
Por exemplo:
Uma classe Usuario seria responsável pelo CRUDE e pelas regras de
negócio envolvidas a ela?
On 12 jun, 08:44, Denis Ferrari <denis.sis...@gmail.com> wrote:
> Bom dia Rene,
>
> Tempos atrás houve um podcast sobre o tema aqui no grupo, se ainda não
> ouviu, recomendo:http://podcast.dotnetarchitects.net/2010/03/podcast-11-modelo-anemico/
>
> Antes de mais nada, é ideal que você se foque menos nos patterns e
> mais na *Linguagem
> Ubíqua* e na *Orientação a Objetos* em si. Essas duas coisas serão o seu
> norte, na hora de modelar o seu domínio. Seguem alguns links de referência:http://livesourcebrasil.blogspot.com.br/2011/02/linguagem-ubiqua-para...
De acordo com o mesmo senário citado pelo Rene, a responsabilidade de
CRUDE fica por conta de cada entidade?
Por exemplo:
Uma classe Usuario seria responsável pelo CRUDE e pelas regras de
negócio envolvidas a ela?
On 12 jun, 08:44, Denis Ferrari <denis.sis...@gmail.com> wrote:
> Bom dia Rene,
>
> Tempos atrás houve um podcast sobre o tema aqui no grupo, se ainda não
> ouviu, recomendo:http://podcast.dotnetarchitects.net/2010/03/podcast-11-modelo-anemico/
>
> Antes de mais nada, é ideal que você se foque menos nos patterns e
> Ubíqua* e na *Orientação a Objetos* em si. Essas duas coisas serão o seu
> norte, na hora de modelar o seu domínio. Seguem alguns links de referência:http://livesourcebrasil.blogspot.com.br/2011/02/linguagem-ubiqua-para...
>
> http://www.heroisdati.com/herocast-aquele-das-tres-regras-da-poo/
>
> Agora sobre suas perguntas:
>
> 1) É possivel aplicar Service pattern em uma aplicação com modelo Rico ?
> Sim, mas geralmente em escala bem menor do que em um modelo anêmico.
>
> 2) Aplicando Repository pattern na aplicação, o repositório terá a
> responsabilidade de salvar as entidades, mais aonde eu irei criar o
> repositorio e encapsulo alguma logica, por exemplo alterar o estado de
> algumas entidades e salva-las?
> É de responsabilidade das próprias classes alterar o seu estado. A sua
> camada de persistência simplesmente persiste tudo ao final. Repositórios
> não possuem Update, isso é transparente.
>
> 3) Injetar ou atribuir um repositorio para uma classe do modelo e dentro
> dessa classe do modelo executar metodos do repositorio é correto?
> Não me parece correto ou usual.
>
> Espero ter ajudado.
>
> Abraços!
>
> Denis Ferrariwww.heroisdati.com
>
> http://www.heroisdati.com/herocast-aquele-das-tres-regras-da-poo/
>
> Agora sobre suas perguntas:
>
> 1) É possivel aplicar Service pattern em uma aplicação com modelo Rico ?
> Sim, mas geralmente em escala bem menor do que em um modelo anêmico.
>
> 2) Aplicando Repository pattern na aplicação, o repositório terá a
> responsabilidade de salvar as entidades, mais aonde eu irei criar o
> repositorio e encapsulo alguma logica, por exemplo alterar o estado de
> algumas entidades e salva-las?
> É de responsabilidade das próprias classes alterar o seu estado. A sua
> camada de persistência simplesmente persiste tudo ao final. Repositórios
> não possuem Update, isso é transparente.
>
> 3) Injetar ou atribuir um repositorio para uma classe do modelo e dentro
> dessa classe do modelo executar metodos do repositorio é correto?
> Não me parece correto ou usual.
>
> Espero ter ajudado.
>
> Abraços!
>
> Denis Ferrariwww.heroisdati.com
>
Felipe Santos
Jun 12, 2012, 7:28:26 PM6/12/12
to .Net Architects
ops: "cenário"
Rodrigo Vidal
Jun 12, 2012, 7:29:22 PM6/12/12
to dotnetar...@googlegroups.com
Idealmente, não.
Denis Ferrari
Jun 13, 2012, 7:36:25 AM6/13/12
to dotnetar...@googlegroups.com
Oi Felipe,
As classes de negócio não sabem nada sobre a persistência. Veja esse link com um exemplo prático:
Rene Felix Correa
Jun 13, 2012, 8:37:24 AM6/13/12
to dotnetar...@googlegroups.com
denis,
muito obrigado ajudou a esclarecer minhas duvidas porem estou com mais uma.
digamos q eu tenha uma validacao na classe de usuario q nao eh permitido adicionar usuarios com login igual como eu faria isso sem ter ligacao com repositorio, seria melhor criar outra classe para essa validacao q conhecesse repositorio ? e com outras validacoes q dependem de informacoes q a classe nao tem como poderia fazer?
eu acho q o conceito de apenas uma responsabilidade por classe iria se aplicar nisso, isso eh correto?
Denis Ferrari
Jun 14, 2012, 4:27:54 PM6/14/12
to dotnetar...@googlegroups.com
Oi Rene,
A classe usuário teria responsabilidade sobre ela própria. A validação em questão é uma operação sobre uma lista de usuários, que geralmente é responsabilidade do repositório.
No método Adicionar do Repositório, você poderia verificar se o usuário já existe e disparar uma exceção. Como a regra é sobre a coleção de usuários, faz sentido que a mesma fique no repositório.
--
Marcus Alexandre Silva
Jun 14, 2012, 4:54:31 PM6/14/12
to dotnetar...@googlegroups.com
Regra de negocio no repositorio? Não gostei...
Denis Ferrari
Jun 14, 2012, 4:58:46 PM6/14/12
to dotnetar...@googlegroups.com
Oi Marcus, como você resolveria?
Fernando Mondo
Jun 14, 2012, 5:03:02 PM6/14/12
to dotnetar...@googlegroups.com
Aí é que entra a camada de Aplicação. ela deve validar o contexto da atividade verificando se a entidade esta adequada para esta ação.
É nela que se encontra estas regras:
Ah quem crie uma especificação na camada de Dominio para ilustrar esta verificação, então a camada de Aplicação chama-a e somente se a espeficação passar é que a entidade é persistida.
Em 14 de junho de 2012 17:54, Marcus Alexandre Silva <inf.marcu...@gmail.com> escreveu:
Denis Ferrari
Jun 14, 2012, 5:11:06 PM6/14/12
to dotnetar...@googlegroups.com
Fernando,
A camada de Aplicação, conceitualmente, é fina e sem regras.
Fernando Mondo
Jun 14, 2012, 7:35:13 PM6/14/12
to dotnetar...@googlegroups.com
A regra não esta na camada de aplicação e sim na especificação, mas é chamada por ela. Tem um exemplo no stackoverflow muito legal, mas estou um celular agora, vou procurar o link amanha...
Denis Ferrari
Jun 14, 2012, 8:29:34 PM6/14/12
to dotnetar...@googlegroups.com
Fernando,
Desculpe, falei bobeira. Não tinha entendido a solução.
Já usei Specification para tirar coisas do repositório e passar para o domínio. Essa estratégica funciona bem. Tem um artigo muito legal no site da Qualidata sobre essa solução:
http://blog.qualidata.com.br/?p=1102
Uma outra alternativa seria usar Domain Events, mas acho essas duas soluções muito "rebuscadas" dependendo do contexto.
O Giovanni escreveu um artigo bem legal sobre Domain Events, segue o link:
Marcus Alexandre Silva
Jun 15, 2012, 8:54:09 AM6/15/12
to dotnetar...@googlegroups.com
Opa. A outra resposta foi por celular, por isto que curta...
Mas parece que vocês ja chegaram em uma solução bem feira.... :)
Ja falei isto por aqui antes, é importante ter em mente que a
implementação do Repositório não faz parte do domínio, mas seu
contrato (interface) é, portanto, regras de negócio não devem (quase
nunca) ser implementadas nesta camada.
Abraço,
Marcus Alexandre
Mas parece que vocês ja chegaram em uma solução bem feira.... :)
Ja falei isto por aqui antes, é importante ter em mente que a
implementação do Repositório não faz parte do domínio, mas seu
contrato (interface) é, portanto, regras de negócio não devem (quase
nunca) ser implementadas nesta camada.
Abraço,
Marcus Alexandre
Denis Ferrari
Jun 15, 2012, 9:16:15 AM6/15/12
to dotnetar...@googlegroups.com
Marcus,
Concordo com você, mas encarar essas coisas como "regras" muitas vezes faz você não solucionar o seu problema da forma mais simples naquele momento. Por isso, depende.
Marcelo Oliveira
Jun 15, 2012, 11:16:21 AM6/15/12
to dotnetar...@googlegroups.com
"faz você não solucionar o seu problema da forma mais simples naquele momento"
o problema é quando a solução é mais simples somente naquele momento... a wild tech debt appears...
Denis Ferrari
Jun 15, 2012, 11:37:06 AM6/15/12
to dotnetar...@googlegroups.com
Um bom profissional precisa ter uma visão completa do cenário.
As vezes, a solução certa toma tempo demais e compromete o objetivo em certo ponto do projeto, mesmo que essa solução seja a melhor segundo o Evans, Fowler, etc. Nesse momento, é criado o débito técnico. Ter débito técnico não é o problema. O problema é nunca quitar o débito.
Se você tem uma solução que não você nunca aplicou, você precisa considerar o tempo de desenvolvimento e o risco por falta de experiência. Usar uma solução temporária é uma estratégia, para pensar melhor sobre a solução final e aplicá-la com um risco menor, sem afetar a entrega de valor e comprometer a performance futura.
O mundo não é preto e branco, existe uma área cinza. Nossa área possui recomendações, mas as pessoas encaram como regras e perdem flexibilidade. Isso é o problema da mente descontínua.
Marcus Alexandre Silva
Jun 15, 2012, 12:12:40 PM6/15/12
to dotnetar...@googlegroups.com
+1
Marcelo Oliveira
Jun 15, 2012, 1:08:42 PM6/15/12
to dotnetar...@googlegroups.com
ué... concordo plenamente... =)
Mas não estamos falando de nenhuma guideline/arquitetura absurdamente dificil de implementar... alguns tradeoffs são válidos 99% das vezes.
2012/6/15 Marcus Alexandre Silva <inf.marcu...@gmail.com>
Denis Ferrari
Jun 15, 2012, 1:33:28 PM6/15/12
to dotnetar...@googlegroups.com
Talvez não seja difícil de implementar para você, mas para quem nunca fez pode ser. Não dá para assumir uma solução sem conhecer a maturidade do time de implementação.
Reply all
Reply to author
Forward
0 new messages