Repositório e Consultas

[Régis Soares]

Pessoal,

 

Hj acordei pensando a respeito de repositórios e consultas.

 

Vamos supor que eu tenha uma raiz de agregação, mas em alguns momentos precise *apenas* consultar os agregados, como por exemplo, Pedido e ItemDoPedido.

 

class Pedido {

  ItemDoPedido[] itens;

}

 

Nesse caso, um requisito funcional é consultar itens do pedido, independente do pedido. Perceba que a funcionalidade somente consulta os itens, nada mais.

 

Pensei em algo como: RepositorioDePedidos e ConsultaDeItensDePedidos, onde o repositório possui toda lógica para persistir os dados de pedidos e seus itens; e a consulta apenas a lógica para consultar os itens.

 

Na linguagem do DDD isso está correto? Ou deveria ter dois repositórios: um para pedidos e outro para os itens?

 

Abraços,

Régis Soares

[Alexandre Valente]

Oi Régis,

No DDD é mais comum vc ter o repositório somente para o aggregate, se pedido concentra tudo ele deveria ser o único (e o repositório faz consultas e gerencia a persistencia). Mas se o seu requisito é consultar itens que não estão vinculados a pedidos, então talvez o item seja um aggregate à parte, merecendo seu proprio repositório.

No nosso caso nós sempre criamos um repositório por entidade (automaticamente por gerador de código), assim a gente nem fica com estas dúvidas existenciais! :-)

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

2009/12/13 Régis Soares <regis...@gmail.com>

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

[tucaz]

Exactly, se vc precisar acessar um child diretamente sem passar pelo
aggregte tem Alguma coisa errada no seu modelo.

On Dec 13, 2:20 pm, Alexandre Valente <alexandre.g.vale...@gmail.com>
wrote:

> Oi Régis,
>
> No DDD é mais comum vc ter o repositório somente para o aggregate, se pedido
> concentra tudo ele deveria ser o único (e o repositório faz consultas e
> gerencia a persistencia). Mas se o seu requisito é consultar itens que não
> estão vinculados a pedidos, então talvez o item seja um aggregate à parte,
> merecendo seu proprio repositório.
>
> No nosso caso nós sempre criamos um repositório por entidade
> (automaticamente por gerador de código), assim a gente nem fica com estas
> dúvidas existenciais! :-)
>
> abs,
>
> Alexandre Valente
> MCSE+I, MCSD, MDCBA, ITIL, CSM
> agvalente.wordpress.com
>

> 2009/12/13 Régis Soares <regissoa...@gmail.com>

>
>
>
> > Pessoal,
>
> > Hj acordei pensando a respeito de repositórios e consultas.
>
> > Vamos supor que eu tenha uma raiz de agregação, mas em alguns momentos
> > precise *apenas* consultar os agregados, como por exemplo, Pedido e
> > ItemDoPedido.
>
> > class Pedido {
> >   ItemDoPedido[] itens;
> > }
>
> > Nesse caso, um requisito funcional é consultar itens do pedido,
> > independente do pedido. Perceba que a funcionalidade somente consulta os
> > itens, nada mais.
>
> > Pensei em algo como: RepositorioDePedidos e ConsultaDeItensDePedidos, onde
> > o repositório possui toda lógica para persistir os dados de pedidos e seus
> > itens; e a consulta apenas a lógica para consultar os itens.
>
> > Na linguagem do DDD isso está correto? Ou deveria ter dois repositórios: um
> > para pedidos e outro para os itens?
>
> > Abraços,
> > Régis Soares
>
> > --
> > 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<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

[Fabiano França]

Eu promoveria ItemDoPedido a uma agregação e criaria um repositório para ele. Nada te impede de criar um repositório de ItensDePedidoComQuantidadeAcimaDe5 (por exemplo).

2009/12/13 Régis Soares <regis...@gmail.com>

Um abraço,

Fabiano França

blog: algumasideias.net
gtalk: fab...@algumasideias.net

"It's a magical world. Hobbes, ol' buddy... let's go exploring!".

[Raphael Cruzeiro]

Pessoal,

Eu gostaria de aproveitar o tópico para perguntar se é vantagem implementar o repositorio como singleton ou se isso vai apenas levar a dores de cabeça futuras.

Obrigado,

Raphael Cruzeiro

[Régis Soares]

Alexandre,

 

Pensei em um modelo onde os itens sempre estão vinculados a um pedido, o que motivou a dúvida

2009/12/13 Alexandre Valente <alexandre...@gmail.com>

[Régis Soares]

Fabiano,

 

Exato, mas nesse caso, meu repositório de itens de pedido teria apenas os métodos de consulta, pois os de insert, update e delete estariam no repositório de pedidos.

2009/12/13 Fabiano França <fab...@algumasideias.net>

[Ricardo Rocha]

Vc escreveu:

"Pensei em um modelo onde os itens sempre estão vinculados a um pedido, o que motivou a dúvida"

Se os modelos estão sempre vinculados a um pedido, vc não precisa ter um repositório diferente.

Observe que vc vai consultar os itens de um PEDIDO ... ou seja, itens é dependente de Pedido .... logo, quem deve responder por isso é Pedido !!

Dependendo da tua necessidade, vc poderia criar um método ListarItens( long pedido ) no repositório de Pedidos. Isso, até onde sei, não "fere" o DDD e resolve teu problema de ter os itens sem trazer dados desnecessários. Não vejo com bons olhos criar outro repositório apenas para fazer isso.

[]'s


Ricardo José Alves da Rocha
Porto Alegre - RS

2009/12/14 Régis Soares <regis...@gmail.com>

[Régis Soares]

Ricardo,

 

Logo abaixo escrevi também que há um requisito funcional consultar itens do pedido, independente do pedido (porém, levando em consideração que um item está sempre vinculado a um pedido)

 

Implementar isso apenas com um repositório para pedidos, do ponto de vista do sistema, talvez não seja uma boa solução, pois terei que listar todos os pedidos e seu itens vinculados para percorrer a lista de itens de todos os pedidos, visto que no contexto de "consultar itens do pedido, independente do pedido" o pedido não é importante.

 

Nesse caso específico pensei em ter dois repositórios, porém o repositório de itens só implementa lógica de consulta (selects)

2009/12/14 Ricardo Rocha <ricardor...@gmail.com>

[Eduardo Costa]

Depende tuca.

Para vc vincular um objeto ao root pode ser que precise por exemplo
listar todas as opções para depois fazer o vinculo.

[Diego Dias]

Mais nesse caso o objeto que será associado tem sua vida propria e teoricamente tem o seu repositorio, assim é totalmente normal que nós usemos o seu repositorio para retornar a lista que for necessária. Acho q esta situação existe mais é diferente da que está em questão aki.

 

E realmente a dúvida do Régis é boa.

2009/12/14 Eduardo Costa <educ...@gmail.com>

[Daniel Porfirio]

Olá Regis,

O que motiva esse requisito de listar itens independentes de pedido? Se for o domínio blz, vamos criar um repositório para isso, mas se for a sua view ou um relatório(Apresentação) e não vejo a necessidade de um repositório.

Não tenho conhecimento da sua app mas acho meio estranho um requisito desse ser um requisito de domínio, mas com ja disse no inicio eu não conheço os requisitos da sua app.
--
[]'s.

A Melhor Maneira De Prever o Futuro é Criá-lo.
------------------------------------------------------------------------------------------------------------------------
Daniel da Silva Porfirio
msn: daniel.s...@gmail.com
------------------------------------------------------------------------------------------------------------------------
Acesse http://www.clickarvore.com.br, registre-se e plante uma árvore diariamente!
Nosso planeta agradece.

[Vinicius Quaiato]

Tucaz,

E se ele quiser, por exemplo, saber os itens que mais são vendidos? Independente de em que pedido foram vendidos?

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

2009/12/13 tucaz <tuc...@gmail.com>

[Daniel Silva]

Oi Regis,

A melhor forma (e única que conheço) de atender este requisito é criando uma consulta no repositório de Pedido que te retorne os Pedidos e os ItensDoPedido que você deseja numa mesma consulta (Eager Load).

Para isso, sugiro que dê uma olhada em Fetching Strategies:

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching

http://www.udidahan.com/2007/04/23/fetching-strategy-design/

Em linhas gerais, sendo Pedido a raiz da agregação, não faz sentido criar um repositório para ItensDoPedido, pois este só possui razão de existir sendo pertencente a um Pedido. 

Suponhamos, por exemplo, que você precise efetuar alguma alteração no ItemDoPedido e disparar um aviso ao Pedido, para que este se atualize. Por mais que sua funcionalidade precise listar somente ItensDoPedido, muito provavelmente alguma alteração precisará ser refletida em Pedido (estado, valor etc), ou você precisará exibir o número do Pedido ao qual o ItemDoPedido faz parte. Por isso, criar um repositório para ItensDoPedido não seria uma boa prática, porque para a suposição citada você precisaria fazer diversas consultas para obter os Pedidos, uma vez que você burlou a agregação e trouxe diretamente os ItensDoPedido.

Enfim. minha sugestão é esta: eager load quando necessário, respeitando o repositório da raiz da agregação.

Abs.

2009/12/13 Régis Soares <regis...@gmail.com>

--

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

--
São Frei Galvão, rogai por nós!

[Daniel Silva]

obs.: indiquei links que falam do NHibernate, mas qualquer bom ORM vai
te oferecer eager load. =)



Em 14/12/09, Daniel Silva<daniels...@gmail.com> escreveu:

> Oi Regis,
>
> A melhor forma (e única que conheço) de atender este requisito é criando
> uma
> consulta no repositório de Pedido que te retorne os Pedidos e os
> ItensDoPedido que você deseja numa mesma consulta (Eager Load).
> Para isso, sugiro que dê uma olhada em Fetching Strategies:
> http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching
> http://www.udidahan.com/2007/04/23/fetching-strategy-design/
>
> Em linhas gerais, sendo Pedido a raiz da agregação, não faz sentido criar
> um
> repositório para ItensDoPedido, pois este só possui razão de existir sendo
> pertencente a um Pedido.
> Suponhamos, por exemplo, que você precise efetuar alguma alteração no
> ItemDoPedido e disparar um aviso ao Pedido, para que este se atualize. Por
> mais que sua funcionalidade precise listar somente ItensDoPedido, muito
> provavelmente alguma alteração precisará ser refletida em Pedido (estado,
> valor etc), ou você precisará exibir o número do Pedido ao qual o
> ItemDoPedido faz parte. Por isso, criar um repositório para ItensDoPedido
> não seria uma boa prática, porque para a suposição citada você precisaria
> fazer diversas consultas para obter os Pedidos, uma vez que você burlou a
> agregação e trouxe diretamente os ItensDoPedido.
>
> Enfim. minha sugestão é esta: eager load quando necessário, respeitando o
> repositório da raiz da agregação.
>
> Abs.

> <http://www.udidahan.com/2007/04/23/fetching-strategy-design/>

>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

[tucaz]

Galera, se voces querem criar repositorios a mais, ok. Escolha de
voces, mas nao faz sentido. Se o ciclo de vida do ItemDoPedido depende
de um Pedido nao tem pq criar outro repositorio. Nao consigo ver uma
ocasiao onde isso faca sentido. Talvez vc nao va exibir os dados do
pedido pq vc ta usando um PopUp dentro de uma tela de pedidos, mas ai
eh problema da sua view e nao do modelo.

Vinicius,

no caso dos mais vendidos ou qualquer outra operacao em agregados a
historia eh diferente. Isso caracteriza um relatorio ou coisa que o
valha. Nao eh uma modelagem normal, mas sim uma query extra em um
servico ou qualquer outra coisa por motivos obvios de performance.

E tem mais, o que ele gostaria de saber sao os produtos mais vendidos
certo? Ja que um item de pedido geralmente eh uma relacao de Produto
com Quantidade. Nesse caso vc poderia ate colocar dentro do
repositorio de produtos que sim, tem um exclusivo so pra ele.

Se voces acham que faz sentido colocar azuleijo no chao da casa de
voces, tudo bem. Quem vai usar o banheiro sao vcs mesmo :P

On Dec 14, 8:42 am, Daniel Silva <danielsilva...@gmail.com> wrote:
> obs.: indiquei links que falam do NHibernate, mas qualquer bom ORM vai
> te oferecer eager load. =)
>

> Em 14/12/09, Daniel Silva<danielsilva...@gmail.com> escreveu:

>
>
>
> > Oi Regis,
>
> > A melhor forma (e única que conheço) de atender este requisito é criando
> > uma
> > consulta no repositório de Pedido que te retorne os Pedidos e os
> > ItensDoPedido que você deseja numa mesma consulta (Eager Load).
> > Para isso, sugiro que dê uma olhada em Fetching Strategies:

> >http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performanc...

> >http://www.udidahan.com/2007/04/23/fetching-strategy-design/
>
> > Em linhas gerais, sendo Pedido a raiz da agregação, não faz sentido criar
> > um
> > repositório para ItensDoPedido, pois este só possui razão de existir sendo
> > pertencente a um Pedido.
> > Suponhamos, por exemplo, que você precise efetuar alguma alteração no
> > ItemDoPedido e disparar um aviso ao Pedido, para que este se atualize. Por
> > mais que sua funcionalidade precise listar somente ItensDoPedido, muito
> > provavelmente alguma alteração precisará ser refletida em Pedido (estado,
> > valor etc), ou você precisará exibir o número do Pedido ao qual o
> > ItemDoPedido faz parte. Por isso, criar um repositório para ItensDoPedido
> > não seria uma boa prática, porque para a suposição citada você precisaria
> > fazer diversas consultas para obter os Pedidos, uma vez que você burlou a
> > agregação e trouxe diretamente os ItensDoPedido.
>
> > Enfim. minha sugestão é esta: eager load quando necessário, respeitando o
> > repositório da raiz da agregação.
>
> > Abs.
> > <http://www.udidahan.com/2007/04/23/fetching-strategy-design/>
>

> > 2009/12/13 Régis Soares <regissoa...@gmail.com>

[Gerson Dias]

Concordo com o tucaz, de qualquer forma, quem saberia quais os produtos mais vendidos é o próprio pedido, até porque o ItemDoPedido só pode ser considerado vendido depois que o Pedido é concluído, pago ou qq coisa do genero. ItemDoPedido é dependente de um Pedido. Também não consigo ver de outra forma.

2009/12/14 tucaz <tuc...@gmail.com>

[Vinicius Quaiato]

Tucaz,

É. Concordo com a abordagem de um Service ou então adicionando esta funcionalidade no repositorio de Produto.

Concordo que não há como, nem por que, existir um repositório para ItemDePedido.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

2009/12/14 tucaz <tuc...@gmail.com>

[Régis Soares]

tucaz,

 

seus argumentos ficaram mais claros a partir da idéia enviada pelo Daniel.

 

realmente faz mais sentido ter apenas o repositório de pedidos, mesmo havendo o requisito informado no início da thread.

 

pode jogar um exemplo de como ficaria a interface (contrato) do serviço que comentou?

2009/12/14 tucaz <tuc...@gmail.com>

[Daniel Silva]

Tucaz,

Não acho que uma operação em agregados seja uma história diferente. Acho que continua dentro do domínio e a saída seja uma query no repositório de Pedido que retorne os Pedidos com os Itens (eager load) que atendam ao filtro especificado.

Se não for assim, e eu tiver nas mãos um ItemDoPedido obtido de uma outra forma sem que saiba qual o Pedido, como serão persisitidas as alterações efetuadas nele se eu não tenho a raiz da agregação, no caso Pedido (que possui repositório)? Através de uma query de update em um serviço?

2009/12/14 tucaz <tuc...@gmail.com>

[tucaz]

Daniel e Regis,

nesse caso eu nao retornaria um ItemDePedido partindo do model, mas
sim um objeto (DTO ou qquer outro nome que vcs queiram dar) contendo
apenas os dados que preciso para exibicao.

A gente pode ficar aqui ate amanha tentando achar problemas pra
solucao. Vao existir, acho que se eu pensar uns 30 segundos consigo
achar um cenario onde nao faca muito sentido, mas eh um exercicio
inutil ja que nao temos nenhum argumento.

A solucao que eu falei acima deve valer pra maioria dos casos reais
onde performance eh importante, ou vcs nao concordam que somar/
totalizar no DB eh muito mais rapido do que operar num agregado
carregado em memoria?

Att.,
Tuca

On Dec 14, 11:30 am, Daniel Silva <danielsilva...@gmail.com> wrote:
> Tucaz,
>
> Não acho que uma operação em agregados seja uma história diferente. Acho que
> continua dentro do domínio e a saída seja uma query no repositório de

> Pedidoque retorne os Pedidos com

> os Itens (eager load) que atendam ao filtro especificado.
>
> Se não for assim, e eu tiver nas mãos um ItemDoPedido obtido de uma outra
> forma sem que saiba qual o Pedido, como serão persisitidas as alterações
> efetuadas nele se eu não tenho a raiz da agregação, no caso Pedido (que
> possui repositório)? Através de uma query de update em um serviço?
>

> 2009/12/14 tucaz <tuca...@gmail.com>

> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>

[Diego Dias]

Segundo as ultimas menssagens o Régis quer os produtos mais vendidos.

Então se for isso mesmo não vejo com bons olhos recuperar os produtos atraves do repositorio de pedidos. Seria mais adequado usar o repositorio de produtos por questão de performance inclusive, pois se for por pedido vc obrigatoriamente carrega pedido -> itens do pedido -> produto, mas se pensar melhor ainda vc vê q a partir de produto tb não fica bom, já q teoricamente produto não conhece o item do pedido, logo acho q seria mais adequado ainda usar um serviço como já foi dito antes e lá dentro vc criar um DTO ou retorna direto os produtos...enfim

 

Resumindo, dependendo da informação que é requerida será definida a forma com q ela será recuperada.

 

2009/12/14 Daniel Silva <daniels...@gmail.com>

[Régis Soares]

eita... já surgiu mais alguns requisitos além do inicial (produtos mais vendidos) e até uma entidade nova (produto). olha o pessoal tentando definir a regra de negócio do cliente! rs

 

o modelo trata apenas de pedidos e itensdepedido. e o requisito é consultar os itens independente do pedido. porém, um itemdopedido é sempre de um pedido.

 

esse não é um problema real, apenas relacionei a esse assunto, pois a maioria conhece o domínio pedidos + itens (sem produtos, por enquanto ;)).

 

a idéia inicial é: diante do requisito de listar todos os itensdepedido, independente do pedido, há a necessidade de mais um repositório (para itens) ou esse método deve ficar no repositório de pedidos (raiz da agregação)

2009/12/14 Diego Dias <diego...@gmail.com>

[Diego Dias]

Que estranho sua surpresa, pois esses requisitos foram mencionados antes da minha mensagem e ninguém se espantou.rs

Voltando a Itens de Pedido, como já foi dito antes não tem pq criar um outro repositorio para responder a Itens de Pedido já q não faz sentido tem um Item de Pedido sem um Pedido, logo para ter acesso aos Itens de um pedido vc precisa do Pedido.

 

No livro do Evans ele menciona isso quando defini repositorios...

 

2009/12/14 Régis Soares <regis...@gmail.com>

[Daniel Silva]

Entendi Tucaz.

Eu apenas fiz uma observação de que caso seja necessária uma operação no ItemDoPedido, não faria sentido procurar uma forma de obtê-lo independente do Pedido se esta operação desdobraria em uma alteração nele, afinal se Item faz parte de uma agregação, supõe-se que deve existir uma coesão nas informações a que ela dá significado.

O Regis citou apenas "listar ItemDoPedido independente do Pedido", eu fui um pouco mais além do que relatório, e supus que caso ele queira listar para depois efetuar alguma alteração no Item que influencie o contexto no qual ele está inserido, a saída seria uma consulta com join que trouxesse essas informações de uma vez só (query com eager load no repositório de Pedido), senão para cada Item seria necessário um novo select para obter seu Pedido, neste caso comprometendo a performance.

2009/12/14 tucaz <tuc...@gmail.com>

[Emmanuel G. Brandão]

Já discutimos isso aqui... O Item do Pedido é uma coisa, ele salva por exemplo o preço do Item nessa Venda. Já Item é outra coisa, vai ser cadastrado antes então é necessário um Repositório pra ele.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

2009/12/14 tucaz <tuc...@gmail.com>

[Giovanni Bassi]

Só lembrando que se você criar um repositório por entidade, ainda que possa estar usando o repository pattern, não está mais utilizando DDD.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/12/13 Alexandre Valente <alexandre...@gmail.com>

[Giovanni Bassi]

Regis,

Consulta não tem nada a ver com repositórios. Repositórios não tem como foco buscar dados para exibir na tela. Eles até podem fazer isso por conveniência, mas seu foco não é esse. Repositórios fingem que são coleções de objetos.
Se sua agregação tem como raiz o pedido, você não pode ter um repositório de itens. Mas nada te impede de criar um objeto de consulta que retorne representações do item para exibir na tela, um bag de dados usado simplesmente para isso. Esse tipo de estrutura de dados não é um objeto, porque objetos pressupõe comportamento, não encontrado nesse tipo de estrutura.
Esse é só o primeiro problema que você vai encontrar quando tentar conjugar contexto de exibição em tela com repositórios. Pode se preparar para problemas similares quando precisar fazer ordenação, paginação, projeções, etc. E a resposta para todos é a mesma que acabo de dar: separe o contexto de leitura do contexto de escrita.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

[Giovanni Bassi]

Dores de cabeça. Das fortes.
Fuja de singletons sempre que possível. E de classes e métodos estáticos também.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/12/13 Raphael Cruzeiro <raphael....@gmail.com>

[Giovanni Bassi]

Segue um link pra ajudar. Escrevi sobre isso faz tempo:

Repositórios não são DAOs:
http://unplugged.giggio.net/post/DDD-Repositorios-nao-sao-DAOs.aspx

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/12/15 Giovanni Bassi <gig...@giggio.net>

[Fabiano França]

Aproveitando a discussão: E quando vocês precisam visualizar/editar um filho especifico, como vocês estão fazendo?

Recuperam o pai e procuram na sua coleção de filhos?

2009/12/15 Giovanni Bassi <gig...@giggio.net>

Segue um link pra ajudar. Escrevi sobre isso faz tempo:

Repositórios não são DAOs:
http://unplugged.giggio.net/post/DDD-Repositorios-nao-sao-DAOs.aspx

[Régis Soares]

Giovanni,

 

Nesses casos de consulta específicos (para apresentação dos dados), sua sugestão é ter um objeto (como um serviço) apenas com comportamentos de consulta que podem retornar objeto do tipo IQueryable, IList, DTOs, etc., onde no contexto de cada comportamento implemento as consultas com HQL, SqlCommand, etc.?

 

abs

2009/12/15 Giovanni Bassi <gig...@giggio.net>

[Régis Soares]

Fabiano,

 

Eu acredito que seja algo como:

 

Pedido pedido = RepositorioDePedidos.ObterPeloId(id);

ItemDoPedido item = pedido.ObterItemPeloId(id);

// altera os dados do item

RepositorioDePedidos.Salvar(pedido);

 

Sintam-se a vontade para refatorar ;)

 

abs

2009/12/15 Fabiano França <fab...@algumasideias.net>

--

[Daniel Silva]

Giovanni,

Cheguei a comentar sobre ordenação e paginação em outra thread.

Encontrei uma solução bastante interessante em: http://thinkbeforecoding.com/post/2009/04/08/Back-on-Repositories-and-Paging-Introducing-reporting#c8505941

2009/12/15 Giovanni Bassi <gig...@giggio.net>

[Fabiano França]

2009/12/15 Régis Soares <regis...@gmail.com>

 

Pedido pedido = RepositorioDePedidos.ObterPeloId(id);

ItemDoPedido item = pedido.ObterItemPeloId(id);

// altera os dados do item

RepositorioDePedidos.Salvar(pedido);

É o que eu tenho feito também.

[Alexandre Valente]

Oi Giovanni,

Sei que isto já foi objeto de outra thread, mas da maneira que vc coloca, "não está mais utilizando DDD" soa como se um pecado capital estivesse sendo cometido! :-)

Como já falamos na outra thread, a proposta de DDD é legal... porém eu jamais vou deixar uma teoria falar mais alto se houver uma maneira mais simples e rápida de fazer.

Não sei se é o caso abaixo. Mas de qqer maneira, continuo defendendo que nosso papel é conhecer tudo e aplicar o que faz sentido.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

2009/12/15 Giovanni Bassi <gig...@giggio.net>

[Gustavo Rocha]

Concordo. Se nao vira Xiismo.

Ai volto a falar sobre o que vejo aqui em algumas citacoes:
   "Capitulo 3, versiculo 4."

Se todo problema bastasse pegar uma pagina do livro de alguem entao teria sido descoberta a bala de prata e nao precisavamos mais estudar nem mesmo receber.

2009/12/15 Alexandre Valente <alexandre...@gmail.com>

[Ricardo Simões]

Oi  Alexandre,

 

Sua teoria faz muito sentido. Contudo entendo que o Giovanni também está certo.

Você pode criar um padrão de desenvolvimento, e isto realmente não é pecado algum.

 

Só que se, esse alguém, alterar a implementação do seu padrão em qualquer grau que seja, passou a ser o padrão de alguém, e não mais o seu padrão.

 

[]'s

 

Ricardo Simões

 

 

2009/12/15 Gustavo Rocha <gustav...@gmail.com>

[Daniel Silva]

Alexandre,

Permita-me fazer um comentário, porque na thread pode-se perceber que defendo a mesma idéia do Giovanni.

Acho que isso se trata de uma questão de ordem prática.

O Régis coloca a dúvida dele da seguinte forma: "Na linguagem do DDD isso está correto?". Isso significa que ele possui uma dúvida sobre como ele deve organizar sua arquitetura na abordagem DDD. Não discordo que devemos conhecer e aplicar tudo  o que faz sentido (tenho certeza que o Giovanni também não discorda), mas talvez isso fosse uma discussão para outra thread, pois esta aqui foi restrita ao DDD. Mas antes disso, acho que devemos usar tudo que faz sentido tomando o cuidado para não perder o sentido da coisa.

Isto significa que, qualquer comentário que indique a ele como organizar a arquitetura de uma forma diferente a que o DDD propõe não acrescentará em nada, ou somente vai gerar confusão, influenciando negativamente.

Ainda, considerando que estamos em uma thread restrita à abordagem DDD, acredito que nada mais natural do que buscarmos, na fonte, o conhecimento necessário para melhor esclarecermos a dúvida do Régis, neste caso o livro. Ora, se uma pessoa escreveu um livro, significa que quis ajudar (por um preço) outras pessoas a desenvolver o raciocínio que ele (autor) desenvolveu através de sua experiência. Imagino que isso deve ter dado muito trabalho... e se foi amplamente difundido, significa que a abordagem, da forma como foi pensada originalmente, funciona.

Abs.

2009/12/15 Alexandre Valente <alexandre...@gmail.com>

--

[Bruno Fiorentino]

     Concordo que xiismo não é bom, precisamos de uma boa dose de pragmatismo. No entanto, também acredito que é importante buscar embasamento em teorias (ex: DDD que abrange a construção de domain models) e saber quando estamos "desrespeitando" algo, "quebrando" uma regra de maneira consciente, ciente dos tradeoffs, em troca de acelerar a construção ( e talvez comprometer a manutenção) de determinado componente.

     Os "super teóricos" são um problema, mas os "super pragmáticos" também. Eu tenho me policiado bastante para buscar o equilíbrio. O desafio é encontrar a linha que separa o "super teórico" do "super pragmático"...

    Não estou criticando diretamente ninguém na thread -- a meu ver produtiva -- é só uma reflexão.

[]s,
 Bruno Fiorentino    

2009/12/15 Gustavo Rocha <gustav...@gmail.com>

[Alexandre Valente]

Oi Daniel,

Concordo plenamente. E se vc olhar a minha primeira resposta, ela começa "em DDD o usual é ter um repositório por aggreate...". Concordo que se alguem fez uma teoria, temos que conhecer e saber quando a violamos.

O meu comentário foi porque quem não conhece pode achar que violar DDD é algo muito ruim, E não acho que deva ser este o sentido. Mas vc está certíssimo.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

2009/12/15 Daniel Silva <daniels...@gmail.com>

[Giovanni Bassi]

Regis, é isso aí. Esse tipo de cenário fica muito bem com IQueryable.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/12/15 Régis Soares <regis...@gmail.com>

[Giovanni Bassi]

Não foi nesse tom, não. Foi só pra esclarecer. Cada um que use o que achar melhor.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/12/15 Alexandre Valente <alexandre...@gmail.com>

[Gustavo Rocha]

Tenho certeza que nao, Bruno e entendo seu raciocinio.

Os "super" sao ruins em qualquer caso. Sempre.

Especificamente sobre DDD o Giovanni esta correto em afirmar que foge do dominio do padrao. Esta certo. Disciplina é o que tras foco e resultado em muitos casos.

Eu nao falei especificamente sobre o comentario do Giovanni mas tenho visto demais por aqui as informacoes milagrosas trazendo a solucao e qualquer pessoa experiente em desenvolvimento sabe que mais importante que tudo que for falado aqui, o que tem mais peso vai ser sempre o "depende".

Sobre DDD realmente ultrapassou-se o limite, mas nao devemos procurar outras visoes? É mal demais? É a oportunidade do exercicio. É isso que deveria nos diferir.

Mater o foco em um dominio de solucao esta certo. Se fere ou muda, fugiu. Mas nao permtiir vislumbrar outras coisas pq na pagina xpto do livro tal do mega world wide technology++ Paulo Coelho Gate diz que nao pode é que me incomoda

2009/12/15 Bruno Fiorentino <bruno.fi...@gmail.com>