Definição de modelagem BD X Modelo de persistencia

158 views
Skip to first unread message

Vinicius Nunes Macedo

unread,
Dec 19, 2012, 11:57:29 AM12/19/12
to dotnetar...@googlegroups.com

Sres. do grupo, boa tarde.

 

Estive hoje com um colega de trabalho discutindo sobre a melhor forma de desenhar um modelo de persistência baseado na tabela, e houve algumas discussões e gostaria de expor para vocês para ver qual seria a melhor abordagem para se definir o padrão para persistência.

 

Existe a seguinte estrutura

 

[tabela produto] ß [tabela relacionamento] à tabela cliente

 

Na tabela de relacionamento existe um campo além das chaves que é um valor único (sem ser o ID) para gerar um código único entre cliente e produto. Essa informação é usada tanto para produto, como para cliente.

 

Agora vem o ponto de discussão

 

Foi criado um modelo que represente produto, ondem umas das propriedade é a lista de cliente, e foi criada um modelo cliente onde umas das propriedades é uma lista de produtos.

 

E em ambos um modelo, foi definido uma propriedade que é o modelo da tabela de relacionamento, para que se possa armazenar o código entre produto e cliente.

 

Ao meu ver, tabela de relacionamento não tem sua representação em modelagem e a informação que é exclusiva na tabela de relacionamento tem que existir nos modelos que a utilizem, ou seja, não se deve criar um modelo exclusivo do relacionamento.

 

E o ponto da discórdia é, deve-se existir a sua representação nos modelos de persistência, ou as suas informações tem que se manipuladas com as entidades que a utilizem?

 

O conceito de persistência seria de 1 para 1 ou no caso de entidades de relacionamento as suas relações que devem manipular as informações?

 

Grato pela colaboração,

 

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

Rafael Ponte

unread,
Dec 19, 2012, 12:49:01 PM12/19/12
to dotnetar...@googlegroups.com

Ola,

Normalmente quando a tabela de relacionamento faz mais do que relacionar tabelas, ou seja, ela possui estado, há grandes chances de ela ser uma entidade no seu dominio.

Para o seu caso, poderiamos considerar uma entidade Item, na qual teria um relacionamento entre Produto e Cliente mais algumas propriedades que reflitam o estado de Item.

--
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
image001.jpg

Vinicius Nunes Macedo

unread,
Dec 19, 2012, 1:10:10 PM12/19/12
to dotnetar...@googlegroups.com

Rafael, obrigado pelo retorno.

 

Porem, no caso da criação da entidade e atribui-las na entidade cliente e produto, eu passo a ter a propriedade duplicada.

 

Por exemplo:

 

Produto com List<Cliente>, tenho a propriedade por cliente, mais no produto. E vice-versa também.

 

Eu poderia criar uma classe adicional para cada entidade com a propriedade e ter uma herança, com isso eu eliminaria a duplicidade, porem creio ser muito trabalho para um resultado simples.

 

Não deve haver uma maneira mais elegante de disponibilizar essa propriedade para ambos os lados?

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 7:26:06 AM12/20/12
to dotnetar...@googlegroups.com
Mas qual seria o problema de ter a propriedade em ambos?

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!
image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 8:05:03 AM12/20/12
to dotnetar...@googlegroups.com

Oi Daniel, bom dia.

 

Voce passa a ter 2x a mesma propriedade.

 

Cliente.propriedade

 

e

 

Cliente.List<Produtos>.propriedade

 

E vice-versa.

 

Ao meu ver isso seria errado, pois estou duplicando a informação e não estaria padronizando de onde ela viria.

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 8:07:37 AM12/20/12
to dotnetar...@googlegroups.com

Oi Charles, bom dia.

 

Para uma modelagem pontual, eu junto com o colega chegamos a conclusão em criar uma classe para produto e outra para cliente com o campo e herdar da classe principal de cada um e com isso remover a duplicidade, porem não sei se é uma “bala de canhão para matar uma mosca”.

 

Quando se existe propriedades na tabela de relacionamento o mais comum é colocar a propriedade na entidade consumidora ou criar uma entidade especifica?

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Charles Mendes
Enviada em: quarta-feira, 19 de dezembro de 2012 16:00
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Re: Definição de modelagem BD X Modelo de persistencia

 

Olá Vinicius, espero ter entendido a sua dúvida...

 

E o ponto da discórdia é, deve-se existir a sua representação nos modelos de persistência, ou as suas informações tem que se manipuladas com as entidades que a utilizem?

Existe modelo de dados e modelo de classes (Entidades).

Quanto ao seu modelo de dados, aparentemente esta correto (Produto - ProdutoCliente - Cliente), esta criando um relacionamento N x N entre Produto e Cliente.

Quanto ao modelo de classes (Entidades), este deve obedecer as necessidades de negócio, e não ser uma cópia exata dos modelos de dados, porém normalmente ficam muitos parecidos.

Pelo que entendi da discussão, ao meu ver esta correto ao criar a Entidade Produto nela você ter uma lista de clientes e o inverso, na Entidade Cliente ter uma lista de produtos.

Para associar ambas entidades, eu aconselharia a criação de um campo "codigoProdutoCliente" em ambas as 2 entidades, sem a necessidade da criação de uma entidade de "ProdutoCliente", não precisaria existir, pois com o campo "codigoProdutoCliente" criado nas 2 entidades (Produto e Cliente), e a já existencia das lista de clientes e lista de produtos, já deve resolver seu problema.

 

Caso você precise utilizar outros campos da tabela de relacionamento ProdutoCliente, além do campo "codigoProdutoCliente", ai sim seria interessante vc criar um modelo de classes Entidade ProdutoCliente, e essa entidade seria conhecida pelas entidades Produto e Cliente.

 

O conceito de persistência seria de 1 para 1 ou no caso de entidades de relacionamento as suas relações que devem manipular as informações?

Continuaria N x N, pois existe lista de produtos na entidade cliente e lista de clientes na entidade produto...

 

 

 

Espero ter ajudado, se eu me precipitei em algo, favor corrigir ai!


Em quarta-feira, 19 de dezembro de 2012 14h57min29s UTC-2, Vinicius Nunes Macedo escreveu:

Sres. do grupo, boa tarde.

 

Estive hoje com um colega de trabalho discutindo sobre a melhor forma de desenhar um modelo de persistência baseado na tabela, e houve algumas discussões e gostaria de expor para vocês para ver qual seria a melhor abordagem para se definir o padrão para persistência.

 

Existe a seguinte estrutura

 

[tabela produto] ß [tabela relacionamento] à tabela cliente

 

Na tabela de relacionamento existe um campo além das chaves que é um valor único (sem ser o ID) para gerar um código único entre cliente e produto. Essa informação é usada tanto para produto, como para cliente.

 

Agora vem o ponto de discussão

 

Foi criado um modelo que represente produto, ondem umas das propriedade é a lista de cliente, e foi criada um modelo cliente onde umas das propriedades é uma lista de produtos.

 

E em ambos um modelo, foi definido uma propriedade que é o modelo da tabela de relacionamento, para que se possa armazenar o código entre produto e cliente.

 

Ao meu ver, tabela de relacionamento não tem sua representação em modelagem e a informação que é exclusiva na tabela de relacionamento tem que existir nos modelos que a utilizem, ou seja, não se deve criar um modelo exclusivo do relacionamento.

 

E o ponto da discórdia é, deve-se existir a sua representação nos modelos de persistência, ou as suas informações tem que se manipuladas com as entidades que a utilizem?

 

O conceito de persistência seria de 1 para 1 ou no caso de entidades de relacionamento as suas relações que devem manipular as informações?

 

Grato pela colaboração,

 

 

 

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

--

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 8:07:41 AM12/20/12
to dotnetar...@googlegroups.com
Natural... se a propriedade é de interesse de ambos cliente e produto... tanto cliente quanto produto terão a propriedade. O fato de cliente ter list<produto> é só um aspecto ortogonal do modelo...

A questão é: qual seria o problema disso?

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 8:10:18 AM12/20/12
to dotnetar...@googlegroups.com

Você criar propriedades duplicadas, e com isso quando você tiver que preencher as informações na propriedade, qual vai ser preenchida. Se chega no ponto de ter que escolher em qual propriedade vai se atribuído o valor, a modelagem esta errada.

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 8:12:01 AM12/20/12
to dotnetar...@googlegroups.com
Espera... o valor não vai ser o mesmo pra ambos cliente e produtos?

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 8:14:16 AM12/20/12
to dotnetar...@googlegroups.com
Vai ficar um pouco mais fácil de entender se vc disser que tipo de propriedade é esta, e o que ela guarda que possa ser interesse de ambas as entidades.
Que valor é este? E por que é de interesse tanto de Cliente quanto Produto?

Agora, na pior das hipóteses, vc mantém a propriedade nos dois objetos... toda vez que um produto for adicionado ao Cliente, o seu ORM já faz o tracking para manter o relacionamento, assim mantendo a integridade do valor...

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 8:15:50 AM12/20/12
to dotnetar...@googlegroups.com

Sim, mais qual propriedade é a correta para preencher?

[Cliente.propriedade] ou [Cliente.List<Produtos>.propriedade]

Não pode existir duas, senão esta errado o conceito. Porem como ela é única, tem que existir um meio de se modelar sem que exista a necessidade de duplicidade.

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 8:17:40 AM12/20/12
to dotnetar...@googlegroups.com

É uma chave gerada para identificar o cliente com o produto, como se fosse um RG que tem que ser exclusivo, porem não pode ser a PK

 

Vendo a visão produto à cliente, eu tenho uma identificação para cada cliente e vice-versa.

Thiago C. Santos

unread,
Dec 20, 2012, 8:18:38 AM12/20/12
to dotnetar...@googlegroups.com

Vinicius, A reclação de cliente e produto é (Cliente - 1..n  -Produto)  ? É exatamente essa a relação?

Se for acho melhor então a propriedade estar em cliente e o produto ter a propriedade que é o cliente.

Cliente.propriedade

Produto.Cliente.Propriedade

Att,

Thiago C. Santos


2012/12/20 Daniel Moreira Yokoyama <moreira....@gmail.com>
image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 8:20:52 AM12/20/12
to dotnetar...@googlegroups.com

Oi Thiago, bom dia.

 

É n..m e com isso a questão, como criar essa propriedade para ambos os lados sem que elas se dupliquem nos objetos.

 

Eu consegui fazer, porem qual seria a modelagem correta para esse contexto, entende?

Thiago C. Santos

unread,
Dec 20, 2012, 8:25:12 AM12/20/12
to dotnetar...@googlegroups.com

Então penso como o Rafael, se esta relação tem um estado(Propriedades) você poderia ter uma enditade/classe que controla este relacionamento.

Att,

Thiago C. Santos


2012/12/20 Vinicius Nunes Macedo <viniciu...@bicbanco.com.br>
image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 8:28:06 AM12/20/12
to dotnetar...@googlegroups.com
Eu sinceramente não entendo o que pode relacionar Cliente e Produto... e anda assim não entendo pq a existência dessa chave... mas o modelo é teu.

O que você precisa fazer é determinar quem é o dono do relacionamento. Como eu não consigo conceber a idéia de Cliente ter Produto... nem Produto ter Cliente não sou eu quem vai te dizer quem é o dono da propriedade.

Se tiver que duplicá-la pq por algum motivo que eu sou incapaz de compreender, o relacionamento pertence a ambos, então não há problema nenhum em duplicar o valor... qualquer ORM lida com isso de forma simples...

Se a idéia é identificar o relacionamento, então estamos falando de uma entidade... aí fica bem mais fácil de resolver... Cria uma entidade com uma propriedade Cliente e outra Produto...... digamos que o modelo sugira que o nome da entidade seja Sbrubles...

Cliente pode manter uma lista de Sbrubles, assim como o produto... toda vez que alguém adicionar um Sbruble ao Cliente, automaticamente seta-se o Cliente da Sbruble com a instancia do Cliente para o qual o Sbruble está sendo adicionado... e vice e versa... (add no Produto.Sbrubles seta o Produto do Sbruble pra instancia do Produto ao qual o Sbruble está sendo adicionado).

Você está tentando normalizar dados onde os dados não precisam estar normalizados... a duplicidade dos valores no modelo não é uma ameaça a tua integridade referencial...


Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 8:30:04 AM12/20/12
to dotnetar...@googlegroups.com
+ 1.

O problema é saber pq Cliente está se Relacionando com produto.

Se nos desse mais informação sobre o que esse modelo está tentando representar, fica mais fácil.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Gerson Dias

unread,
Dec 20, 2012, 8:48:14 AM12/20/12
to dotnetar...@googlegroups.com
Exato, podemos mesmo ajudar melhor se vc nos explicar qual o contexto da coisa toda... se produto for algo que alguém compra (como numa loja virtual) podemos te dar uma sugestão, se produto for um módulo de um sistema em que o cliente tem acesso, te diremos outra coisa. Mas de qualquer forma, lembre-se sempre que quem norteia o modelo do software deve ser o negócio. Pq o cara de negócio gostaria de saber que clientes tem o produto? pq ele quer saber que produtos tem clientes? os nomes das entidades são produto e cliente mesmo?
image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 8:49:52 AM12/20/12
to dotnetar...@googlegroups.com
Para constar, tenho algo parecido no modelo que eu estou usando agora... nada complicado:

Tenho uma campanha promocional que gera cupons que são associados aos clientes. Clientes possuem cupons gerados por uma campanha...

Para fins de monitoramento, eu preciso que a campanha conheça todos os cupons gerados (Campanha.Cupons)... mas o meu cliente, também precisa saber quais cupons ele tem... (Cliente.Cupons), no entanto, o cupom em si sabe à qual Campanha ele pertence (Cupom.Campanha) e a qual cliente ele está associado Cupom.Cliente.

Tudo o que eu precisei fazer foi mapear o relacionamento das 3 entidades (na verdade, Cupom é um VO) no meu ORM (que por motivos de frescura do cliente em usar somente produtos da MS, é o EF5... mas que lida muito bem com esse tipo de associação).

Ao criar um novo cupom e incluí-lo no Cliente.Cupons (Eu odeio modelos em português, mas fiz isso aqui pra ficar claro) Eu nem preciso ajustar o Cupom.Cliente... o próprio ORM resolve isso pra mim quando eu fizer o push.

Eu tenho Cupons em ambas entidades, e o cupom conhece ambos...  Not big deal... não tive problema nenhum pra mapear isso.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 8:52:26 AM12/20/12
to dotnetar...@googlegroups.com
Muito bem lembrado, Gerson...

O Modelo existe pra obedecer critérios do negócio... Então este relacionamento precisa ser, de alguma forma, expresso em negócio. Que tipo requisito seu negócio tem para sugerir que Cliente e Produto precisam ser associados?

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:02:44 AM12/20/12
to dotnetar...@googlegroups.com

Daniel, o contexto é assim:

 

Eu tenho um produto “cartão de credito” que pode ter varias operadoras(CIELO,VISA,REDECARD, etc.)

 

Cada cartão que é registrado em uma operadora ele ganha um numero da operadora que é único, como um ID e não se repete independente da operadora.

 

A modelagem é uma tabela de parametrização onde eu tenho um cartão cadastro para n operadoras que por sua vez gera esse ID.

 

Então se eu quero saber quais operadoras tem um determinado produto, ele vai me trazer os ID de cada operadora, então o ID pertence a operadora.

 

No caso contrario o ID pertence a produto e por esse motivo que não se pode duplicar a propriedade, pois se as entidades recebem uma lista da outra entidade, e com isso a propriedade se repte.

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:06:13 AM12/20/12
to dotnetar...@googlegroups.com

Mais se eu referenciar a entidade do relacionamento na entidade que precisa da informação ela será duplicada da mesma maneira.

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:07:11 AM12/20/12
to dotnetar...@googlegroups.com

Oi Gerson, como eu mandei para o Daniel,

 

Eu tenho um produto “cartão de credito” que pode ter varias operadoras(CIELO,VISA,REDECARD, etc.)

 

Cada cartão que é registrado em uma operadora ele ganha um numero da operadora que é único, como um ID e não se repete independente da operadora.

 

A modelagem é uma tabela de parametrização onde eu tenho um cartão cadastro para n operadoras que por sua vez gera esse ID.

 

Então se eu quero saber quais operadoras tem um determinado produto, ele vai me trazer os ID de cada operadora, então o ID pertence a operadora.

 

No caso contrario o ID pertence a produto e por esse motivo que não se pode duplicar a propriedade, pois se as entidades recebem uma lista da outra entidade, e com isso a propriedade se repte.

 

Creio que a modelagem consiste em trazer as propriedades reais e não duplicadas, pois isso fere a normalização entende.

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 9:08:46 AM12/20/12
to dotnetar...@googlegroups.com
Cara... a duplicidade no objeto não implica em duplicidade no seu modelo relacional.

Uma coisa é uma coisa... outra coisa é outra coisa...

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Gerson Dias

unread,
Dec 20, 2012, 9:09:00 AM12/20/12
to dotnetar...@googlegroups.com
E pq a operadora gostaria de saber todos os cartões que estão associados a ela? Que ações uma operadora pode tomar quem englobe todos os cartões que ela opera?

Será que não é o cartão que deveria saber quais são suas operadoras associadas? É realmente mandatório à operadora saber quais cartões ela opera?



2012/12/20 Vinicius Nunes Macedo <viniciu...@bicbanco.com.br>
o caso contrario o ID pertence a produto e por esse motivo que não se pode duplicar a propriedade, pois se as entidades recebem uma lista da outra entidade, e com isso a propriedade se repte.

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 9:10:29 AM12/20/12
to dotnetar...@googlegroups.com
Então quem tem a propriedade é o Cliente.

Cliente tem Cartão de Crédito... O cartão de crédito do Cliente é um VO que possui a bandeira e o número do Cartão.

É muito mais simples do que vc tá fazendo parecer.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:13:18 AM12/20/12
to dotnetar...@googlegroups.com

Então Gerson, no contexto eu preciso das duas visões, ai que rolou o dilema da propriedade.

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Gerson Dias
Enviada em: quinta-feira, 20 de dezembro de 2012 12:09
Para: dotnetar...@googlegroups.com
Assunto: Re: [dotnetarchitects] Definição de modelagem BD X Modelo de persistencia

 

E pq a operadora gostaria de saber todos os cartões que estão associados a ela? Que ações uma operadora pode tomar quem englobe todos os cartões que ela opera?

--

Thiago C. Santos

unread,
Dec 20, 2012, 9:13:35 AM12/20/12
to dotnetar...@googlegroups.com

Acho que a solução realmente é a de criar uma entidade/classe para o relacionamento. Se você fizer o dao não estará duplicado, o que acontecerá é que a partir das duas classes você conseguira acessar este dado, isto não tem problema algum.
image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 9:14:51 AM12/20/12
to dotnetar...@googlegroups.com
Peraí... o que o Produto faz nesse contexto todo? Quem é produto? O Cartão? A Operadora? 

Tá muito confuso isso.

Cliente tem Cartão de Crédito. Cartão de Crédito tem número e tem de Qual Operadora ele pertence.

Se é tão importante que a Operadora saiba os  cartões, é só uma issue de mapear essa associação. Não é nada... mas eu acho esse modelo definitivamente muito estranho... quem é produto nessa parada toda?


Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Thiago C. Santos

unread,
Dec 20, 2012, 9:16:50 AM12/20/12
to dotnetar...@googlegroups.com
Produto = Cartão
image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:17:03 AM12/20/12
to dotnetar...@googlegroups.com

Voce esta tendo a visão 1..n  e a visão é n..m.

 

E a entidade é cartão e não cliente.

 

E a pergunta é simples, como fazer para que a propriedade não se repita no conceito de negocio, pois na modelagem de bd, isso é resolvido com a tb de relacionamento, na modelagem de entidade é o que eu queria saber qual a melhor pratica para conceber as entidades.

Thiago C. Santos

unread,
Dec 20, 2012, 9:17:17 AM12/20/12
to dotnetar...@googlegroups.com
Cliente = Operadora

Pelo menos é oque eu entendi.

Att,

Thiago C. Santos


2012/12/20 Thiago C. Santos <thiago.c...@gmail.com>
image001.jpg

Thiago C. Santos

unread,
Dec 20, 2012, 9:18:08 AM12/20/12
to dotnetar...@googlegroups.com
Agora confundiu tudo!
image001.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:18:09 AM12/20/12
to dotnetar...@googlegroups.com

Cara, deleta....hehehe cliente X produto foi sé para exemplificar, como vocês queriam saber o contexto real eu enviei, então cliente X produto você esquece...rs

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:18:17 AM12/20/12
to dotnetar...@googlegroups.com

Isso

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 9:18:58 AM12/20/12
to dotnetar...@googlegroups.com

Exatamente, como vcs pediram o contexto real, eu enviei, produto x cliente era só exemplo, então esse vcs esquecem.

Gerson Dias

unread,
Dec 20, 2012, 9:37:23 AM12/20/12
to dotnetar...@googlegroups.com
então vamos lá, pelo que entendi um cartão de crédito pode ter diversas operadoras e uma operadora pode operar diversos cartões, daí vem teu modelo n..n. 

Não discordo que seja um modelo N..N (pelo que vc falou o cartão pode ter diversas operadoras, o que é um tanto estranho pra mim, mas como não estou no contexto do teu negócio não posso opinar). Porém, quando tratamos do tal do DDD temos o conceito da raiz da agregação, que é o ponto de entrada para diversas operações que determinada "área" do teu domínio irá tratar.

Em um primeiro momento creio que Cartão é tua raiz da agregação. Então cartão tem a lista de operadoras que o operam. Porém, creio, que do ponto de vista de negócio, a operadora não deveria saber _todos_ os cartões que ela opera, pois isso seria um tanto inviável (devem ser muitos!). Creio que se vc quer saber todos os cartões que são operados pela CIELO, (pensando em tabelas) basta vc fazer um select simples em cartões where operadora == "CIELO". Para vc saber se é isso mesmo, basta pensar se em algum momento a CIELO irá fazer alguma operação que envolva todos os seus cartões operados.

Claro que no caso do código pode ser que fique mais fácil se vc tiver a lista de cartões direto na operadora, porem, tome cuidado com referencias circulares, principalmente na hora de serializar para um json da vida... Neste caso, só se isso for MTO necessário, duplique, mas deixe o set encapsulado no cartão (cartão.adicionarOperadora(Operadora op) {this.Operadoras.Add(op); op.Cartoes.Add(this);}).

Bom, é isso que eu posso te sugerir por agora...

ps.: @Daniel: pq esse ódio todo por domínios em português? vc não acha que o domínio deve ser feito na lingua que o negócio fala?




image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 10:24:40 AM12/20/12
to dotnetar...@googlegroups.com
Vinícius, talvez seja bom vc ler o livro do Evans... faz vc ter outra idéia sobre como modelar domínio.

@Gerson
Discussão antiga, ...

Português não é muito compatível com as linguagens de programação, e vc abre mão de acentos e coisas típicas da língua... e ainda que eu tolere isto, ainda tenho que lidar com o fato de que a linguagem de programação em si (sua sintaxe) está em inglês... eu acho horrível ver misturas como public void Salvar().

Acho que o modelo deve refletir o negócio no aspecto semântico... mas não acho que isso envolva o aspecto linguístico... já que o domínio é o domínio... independente do idioma.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Gustavo Cruz

unread,
Dec 20, 2012, 10:45:10 AM12/20/12
to dotnetar...@googlegroups.com
"E a pergunta é simples, como fazer para que a propriedade não se repita no conceito de negocio, pois na modelagem de bd, isso é resolvido com a tb de relacionamento, na modelagem de entidade é o que eu queria saber qual a melhor pratica para conceber as entidades"

Vinícius, você está indo pelo caminho errado.
Fazer com que a propriedade não se repita, literalmente, não vai tornar o seu domínio válido.

Tente pensar no negócio e esqueça o que está no banco. Se você cria um relacionamento errado entre entidades no seu domínio, a dor de cabeça depois vai ser bem maior. Tente expor bem a situação pra gente, o cenário, como ele se aplica e por quais motivos.

 Somente responder sua questão pode parecer simples, mas acredito que a maioria aqui, com níveis aguçados de arquitetura, não vai simplesmente te dar a solução sem entender o contexto ;)

Assim como @Daniel, até agora não consegui identificar o PORQUE de utilizar o relacionamento dessa forma. Abra mais o contexto, pois seu problema pode estar na modelagem do seu domínio e não no problema que você expôs.
image001.jpg

Gerson Dias

unread,
Dec 20, 2012, 10:51:20 AM12/20/12
to dotnetar...@googlegroups.com
@Daniel: hmmm.... tenho que discordar.... o domínio é a representação de uma realidade e a realidade é a representação do modelo mental que reflete determinado aspecto que é observado no mundo. Estes aspectos são modificados por questões culturais e linguísticas. Imaginemos que façamos um modelo para um objeto onde as pessoas podem entrar e este objeto irá acelerar e começará a voar. Se estivermos falando da nossa cultura, que já tem todos os conceitos vindos da aviação, o negócio e eu saberei que aquilo é um avião e posso chamá-lo assim. Se estivermos em uma cultura alienígena, aquilo pode se chamar "disco voador", se estivermos numa cultura indígena, aquilo pode ser o "pássaro de ferro". Entende, um conceito pode ser expressado de diversas formas, dependendo da cultura ou da lingua daquele que esta te passando o conhecimento. Infelizmente (ou felizmente) semânticas não são idênticas em diferentes linguas.... haja visto o conceito de valor (value) que é diferente no ingles e no portugues, ou aquele lugar comum da "saudade" que é diferente do "i miss you" dos ingleses.

(peço alguma licença para os exemplos forçados que eu descrevi! hehehehe).

Mas enfim, tema para um novo tópico. 
image001.jpg

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 10:59:37 AM12/20/12
to dotnetar...@googlegroups.com
Não quero prolongar o OFF... mas o avião é avião... mesmo que os índios o chamem de pássaro de ferro. E a idéia da saudade existe pra todo mundo, mesmo quando não há uma palavra que a descreva.
É isso que eu tô falando: o domínio tá lá e transcende as diferenças linguísticas e culturais.
Mas o Bassi já brigou bastante comigo por causa disso... segundo ele a Ubiquitous Language se trata também das questões de linguística. Eu mantenho o não. E odeio ter que lidar com EAtivo ou EhAtivo, sendo que nenhum reflete fielmente o idioma português... (há quem use ÉAtivo... o que é bem pior). 

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Marcus Alexandre Silva

unread,
Dec 20, 2012, 11:12:35 AM12/20/12
to dotnetar...@googlegroups.com
Ubiquitous Language tem a ver com com falar (e usar) o mesmo nome para classes, atributos e métodos que os utilizados nos jargões pelos especialistas do negócio. 
Se seus especialistas falam português você perde ao precisar de ficar buscando traduções para seu código. Llembre-se que  seniores devem programar para que juniores entendam, assim como poliglotas devem escrever seu domínio para que pessoas monoglotas entendam.
Não vejo problema nenhum em colocar seu domínio todo em inglês se a corporação que você trabalha é composta por especialistas de negócio que falem inglês no dia a dia para definição das regras do seu trabalho :)
Só fico me imaginando (neste exato momento estou em um projeto de inovações em um sistema de folha de pagamento) chegar na equipe de especialistas de departamento pessoal falando, escrevendo e especificando regras em inglês sobre regras que são exclusivamente brasileiras... 
DDD é isto.

Em 20 de dezembro de 2012 13:59, Daniel Moreira Yokoyama <moreira....@gmail.com> escreveu:
Ubiquitous Language

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 11:23:45 AM12/20/12
to dotnetar...@googlegroups.com
Isso sempre foi uma questão de preferência... mas dizer que DDD é sobre isso é exagero. DDD é sobre modelar o domínio de acordo com negócio, e refletir esse modelo no código, sem ambiguidades.
DDD não fala nada sobre idiomas...
A questão de regras que exclusivamente brasileiras poderia ser uma circunstância que me forçaria a mudar de idéia... mas não é o contexto onde estou trabalhando. 
Eu não me perco buscando traduções para o meu código, e não tenho culpa se alguém resolveu ser monoglota... (sim, no século XXI eu realmente acho que só é monoglota quem optou por ser).
Eu nasci em 81... entrei no ginásio em 92... e desde que me conheço por gente minha mãe dizia: tem que saber inglês... ou seja, não é de hoje que todo mundo sabe que precisa aprender a falar esse idioma, até eu que não sou corporativista e nem paga-pau de americanos sempre soube que precisava dele, sobretudo para trabalhar com TI.

Agora, quero dizer que não é sobre certo e errado aqui. Eu não acho errado modelar em português. Só acho feio.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


Vinicius Nunes Macedo

unread,
Dec 20, 2012, 11:26:32 AM12/20/12
to dotnetar...@googlegroups.com

Gustavo, obrigado pelo parecer.

 

A questão é simples:

 

 

 

A coluna da tabela VSS_REL_PRD_ADQT, contem a propriedade COD_SRE. (Só não repare nas nomenclaturas, não fui eu que defini....)

 

Eu só queria saber baseado na experiência do grupo a maneira mais adequada de expor a coluna COD_SRE na entidade VSS_PRD (cartão) e VSS_ADQT(operadora)

 

Segue abaixo em vermelho o meu questionamento. Não sei se é o mais “correto” ou se deveria criar uma classe especifica  com a propriedade e herdar em cada um das classes para que não fosse obrigado a duplicidade.

 

public class ProdutoInfo

    {

        public ProdutoInfo()

        {

            listaAdquirentes = new List<AdquirenteInfo>();

        }

 

        public Int32 codigo_produto { get; set; }

        public string nome_produto { get; set; }

        public string numero_conta { get; set; }

        public string tipo_produto { get; set; }

        public int codigo_empresa { get; set; }

        public int codigo_processadora { get; set; }

        public string codigo_bin { get; set; }

 

        public List<AdquirenteInfo> listaAdquirentes { get; set; } // O ponto da duvida

    }

 

    public class AdquirenteInfo

    {

        public AdquirenteInfo()

        {

            relacionamento = new RelacionamentoProdutoClienteInfo();

        }

 

        public int codigo_adquirente { get; set; }

        public string nome_adquirente { get; set; }

        public bool selecionado { get; set; }

 

        public RelacionamentoProdutoClienteInfo relacionamento { get; set; }  // O ponto da duvida

 

    }

 

    public class RelacionamentoProdutoClienteInfo

    {

        public int codigo_produto { get; set; }

        public int codigo_adquirente { get; set; }

        public decimal codigo_sre { get; set; }

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 11:29:43 AM12/20/12
to dotnetar...@googlegroups.com
Vinícius

Eu ainda acho que vc tá muito focado em obedecer teu modelo relacional e trazer ele pro seu modelo de objetos, cara...

Eu sugiro altamente que resolva seu modelo sem pensar no relacional, e quando tiver com ele fechado, aí sim vc determina o impacto que o seu modelo tem sobre ele.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image002.png
image003.jpg

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 11:31:03 AM12/20/12
to dotnetar...@googlegroups.com

Mesmo que isso seja trazer no modelo informações que não pertença a entidade, como no caso do relacionamento? Não fere o conceito de OO?

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 11:34:01 AM12/20/12
to dotnetar...@googlegroups.com
Mas este é o ponto, cara... vc está determinando as informações da entidade baseado no seu modelo relacional...
Reveja o requisito do negócio, modele baseado nele, e no fim veja como isso implica no seu relacional.
A normalização de dados só se aplica no último.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


...

[Mensagem cortada]  

image002.png
image001.jpg

Marcus Alexandre Silva

unread,
Dec 20, 2012, 11:35:55 AM12/20/12
to dotnetar...@googlegroups.com
Que é feio eu concordo e muito com você... :)
Você não esta errado e sua mãe lhe deu o melhor concelho do mundo... Só não ache que você ainda é regra, você é uma exceção. 
E nunca é sobre certo e errado, é sobre contextos...

Agora, voltando ao post do nosso amigo.....
Alguém tem mais alguma sugestão para ele?

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 11:42:49 AM12/20/12
to dotnetar...@googlegroups.com

Bem Daniel, no final o conceito é esse mesmo. É que quanto mais próximo conseguimos igualar, melhor a leitura e interpretação.

 

Mais seu ponto de vista não esta errado.

 

Valeu a todos pelas dicas e o bate papo do cenário....

 

Brigadão a todos.

--

Thiago C. Santos

unread,
Dec 20, 2012, 12:10:23 PM12/20/12
to dotnetar...@googlegroups.com

Vinicius, você não poderia em ambos ter uma lista com todos os relacionamentos que pertencem e em cada relacionamento ter a propriedade?

Att,

Thiago C. Santos


2012/12/20 Vinicius Nunes Macedo <viniciu...@bicbanco.com.br>
D (cartão) e VSS_ADQT(

Vinicius Nunes Macedo

unread,
Dec 20, 2012, 12:31:20 PM12/20/12
to dotnetar...@googlegroups.com

Thiago,

 

Ate poderia mais com isso eu teria a propriedade duplicada de qualquer maneira. Uma na entidade e outra na lista

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Thiago C. Santos
Enviada em: quinta-feira, 20 de dezembro de 2012 15:10
Para: dotnetar...@googlegroups.com
Assunto: Re: [dotnetarchitects] Definição de modelagem BD X Modelo de persistencia

 

 

Vinicius, você não poderia em ambos ter uma lista com todos os relacionamentos que pertencem e em cada relacionamento ter a propriedade?

--

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 12:58:31 PM12/20/12
to dotnetar...@googlegroups.com
Eu já disse que isso não é um problema. Você está tentado usar seu modelo OO para normalizar dados... OO não normaliza dados. Seu ORM, bem mapeado, cuidaria de adaptar pro banco.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Antonio Pedro

unread,
Dec 20, 2012, 2:08:04 PM12/20/12
to dotnetar...@googlegroups.com
@Daniel,

Sou obrigado a discordar...

O elemento mais importante do DDD é a linguagem onipresente, gostemos ou não de programar/modelar na língua nativa de seu especialista do negócio, temos que falar a mesma língua.

Tanto, que a modelagem deve ser feita falando em voz alta, para depois transpormos a mesma para diagramas/código.

Att,

Antonio Nascimento


Date: Thu, 20 Dec 2012 14:23:45 -0200
Subject: Re: [dotnetarchitects] Definição de modelagem BD X Modelo de persistencia
From: moreira....@gmail.com
To: dotnetar...@googlegroups.com

Daniel Moreira Yokoyama

unread,
Dec 20, 2012, 2:28:15 PM12/20/12
to dotnetar...@googlegroups.com
@Antônio... pode discordar.

Eu continuo achando que a Ubiquitous Language não se trata de idioma... se trata da linguagem de negócio... contabilidade é um negócio que existe aqui e no mundo todo... o idioma difere, mas o negócio é o mesmo.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


Capetonis

unread,
Dec 23, 2012, 8:56:51 PM12/23/12
to dotnetar...@googlegroups.com
Confesso que quando li o seu código eu desanimei. E olha que li a Thread toda.

Cara, com o que você tem em mão pra trabalhar (me refiro a se ver obrigado a criar uma classe chamada ProdutoInfo, mapeando as propriedades de qualquer jeito adicionando por exemplo a propriedade neste ProdutoInfo codigo_empresa como int e não uma referência ao objeto empresa), é melhor abrir uma conexão na tela, dar data bind nas suas combos ou grids ou seja lá o que for que quer fazer direto numa conexão aberta em um data adapter pro reader lá e tal (isso mesmo, a parte que o Evans fala em heresia no blue book!), e segue o enterro! Pegue o seu relacional e jogue (vomite) na tela.

Desculpe a sinceridade, vey.

Marcus Alexandre Silva

unread,
Dec 24, 2012, 11:51:36 PM12/24/12
to dotnetar...@googlegroups.com
Bacana a sua sinceridade meu amigo. Agora, qual a solução proposta mesmo?

Vinicius Nunes Macedo

unread,
Dec 27, 2012, 7:09:38 AM12/27/12
to dotnetar...@googlegroups.com

Capetonis, obrigado pelo seu retorno agora lhe pergunto?

 

POR QUE VOCE PARTICIPA DE UM FORUM DE ARQUITETURA MESMO?

 

O grupo de “fodasticos” é em outra lista, aqui as pessoas trocam experiência para se ajudarem mutuamente.

 

Comentários pejorativos que não levam a lugar nenhum... guarda para você.

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Capetonis
Enviada em: domingo, 23 de dezembro de 2012 23:57
Para: dotnetar...@googlegroups.com
Assunto: Re: [dotnetarchitects] Definição de modelagem BD X Modelo de persistencia

 

Confesso que quando li o seu código eu desanimei. E olha que li a Thread toda.



Cara, com o que você tem em mão pra trabalhar (me refiro a se ver obrigado a criar uma classe chamada ProdutoInfo, mapeando as propriedades de qualquer jeito adicionando por exemplo a propriedade neste ProdutoInfo codigo_empresa como int e não uma referência ao objeto empresa), é melhor abrir uma conexão na tela, dar data bind nas suas combos ou grids ou seja lá o que for que quer fazer direto numa conexão aberta em um data adapter pro reader lá e tal (isso mesmo, a parte que o Evans fala em heresia no blue book!), e segue o enterro! Pegue o seu relacional e jogue (vomite) na tela.

Desculpe a sinceridade, vey.

Em quinta-feira, 20 de dezembro de 2012 14h26min32s UTC-2, Vinicius Nunes Macedo escreveu:

Gustavo, obrigado pelo parecer.

 

A questão é simples:

 

 

 

A coluna da tabela VSS_REL_PRD_ADQT, contem a propriedade COD_SRE. (Só não repare nas nomenclaturas, não fui eu que defini....)

Vinicius Nunes Macedo

 

 

Vinicius Nunes Macedo


Att,

 

Thiago C. Santos

 


Att,

 

Thiago C. Santos

 

 

 

Vinicius Nunes Macedo


Att,

 

Thiago C. Santos

 

 

 

Vinicius Nunes Macedo


Att,

 

Thiago C. Santos

 

 

 

Vinicius Nunes Macedo

 

Vinicius Nunes Macedo

 

 

Vinicius Nunes Macedo

Vinicius Nunes Macedo

Thiago C. Santos

unread,
Dec 27, 2012, 7:23:42 AM12/27/12
to dotnetar...@googlegroups.com

Capetonis, a patada foi desnecessária você podia ter dado um feedback mais construtivo do que pejorativo... Porém você atentou a algo que na correria eu não reparei.

"...adicionando por exemplo a propriedade neste ProdutoInfo codigo_empresa como int e não uma referência ao objeto empresa."

Vinicius, o mais correto seria você realmente colocar na propriedade na classe o tipo da classe referenciada e não um int que guarda a chave da referencia, por que se você tiver somente o int você não podera fazer a consultar dados da classe "ProdutoInfo" e apartir dela acessar a classe referenciada, teria que fazer uma nova consulta para puxar os dados do relacionamento. 

O mesmo se aplica na classe:

public class RelacionamentoProdutoClienteInfo

    {

        public int codigo_produto { getset; }

        public int codigo_adquirente { getset; }

        public decimal codigo_sre { getset; }

    }


poderia ser:


public class RelacionamentoProdutoClienteInfo

    {

        public ProdutoInfo produtoInfo { getset; }

        public AdquirenteInfo adquirenteInfo { getset; }

        public decimal codigo_sre { getset; }

    }


Somente estou tentando transformar em algo maus construtivo.

Att,

Thiago C. Santos


2012/12/27 Vinicius Nunes Macedo <viniciu...@bicbanco.com.br>
...

[Message clipped]  

image001.jpg

Priscila Mayumi Sato

unread,
Dec 27, 2012, 8:25:58 AM12/27/12
to dotnetar...@googlegroups.com
Pois é, pois é, pois é... justo eu não tinha participado da thred, peço perdão por isso.

Gente,

eu li por cima tudo, mas pelo que eu entendi o principal problema é ver que algumas pessoas querem deixar o banco de dados relacional exatamente igual as suas classes, e nem sempre dá para fazer isso, nem sempre é lógico fazer isso. Mesmo usando um ORM (eu vi o Yokoyama torcendo o nariz pro EF5 alguns emails atras nessa thread) ainda estamos falando de duas coisas diferentes, dois cenários diferentes.

Sobre a sugestão do Thiago C. Santos eu acho mais apropriada. Na verdade fica parecendo uma adaptação de uma solução NoSQL de um banco de dados de graphos para isso.
E aí vai outra sugestão: você precisa guardar informações sobre relacionamentos entre entidades? Em outros casos dentro desse mesmo sistema?
Então que tal usar um tipo misto onde essas informações fiquem em uma base de dados de graphos?

Até mais, meninos, e não se matem :D

Att,

Thiago C. Santos


<p class="MsoNormal" style="text-...
Mostrar original

Vinicius Nunes Macedo

unread,
Dec 27, 2012, 8:44:04 AM12/27/12
to dotnetar...@googlegroups.com

Oi Priscila e Thiago, obrigado pelo feedback e desculpe a retomada do assunto dessa maneira, mais vamos lá.

 

Quando criamos a entidade de relacionamento com outras entidades ao invés de primitivos realmente é valido para questão de manutenção, porem você vai ter uma entidade com varias propriedades que não serão utilizadas, ou seja, desde que se tome como base popular sempre o primeiro nível, tudo bem, que é o que acontece com a maioria das entidades, porem o TDD diz que se deve resolver o problema da maneira mais simplista possível, então criar uma entidade relacionada com outras entidades que sejam com 5 propriedades cada, teremos uma entidade com 9 propriedades que não serão utilizada para somente usar uma? Será que vale a pena mesmo criar uma estrutura dessa para somente uma propriedade?

 

A questão não é deixar o modelo de negocio igual ao relacional, a questão é: até que ponto é valido criar a entidade de relacionamento para distribuir uma informação que pode pertencer as duas entidades ou simplesmente criar a propriedade nas duas entidades?

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Priscila Mayumi Sato
Enviada em: quinta-feira, 27 de dezembro de 2012 11:26
Para: dotnetar...@googlegroups.com
Assunto: Re: [dotnetarchitects] Definição de modelagem BD X Modelo de persistencia

 

Pois é, pois é, pois é... justo eu não tinha participado da thred, peço perdão por isso.


Att,

 

Thiago C. Santos

 

 

 

Vinicius Nunes Macedo

--

Daniel Moreira Yokoyama

unread,
Dec 27, 2012, 8:49:57 AM12/27/12
to dotnetar...@googlegroups.com
Cara...

Vc está confundindo ou distorcendo o princípio do TDD. Seu modelo precisa ser estabelecido... um int não tem valor semântico além de ser um int (números inteiros de - alguns milhões até mais alguns milhões... isso não significa nada). Agora uma entidade, tem valor semântico mais significativo que um inteiro.

Este é o seu modelo, e o TDD não deveria determinar isso... Ele tira complexidade do código, mas não mata seu modelo.

Além do mais, essa tua neura por x propriedades é insensata: você pode usar lazyloading, que só vai carregar a entidade se vc precisar dela. E se vc precisar dela só para pegar o Id, não tem problema nenhum trazer com ele outras propriedades, afinal ele faz isso uma vez só... vc fala como se o ORM fizesse um roudtrip no banco pra fazer fetch de cada valor da propriedade, e isso não é assim.



Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


image001.jpg

Priscila Mayumi Sato

unread,
Dec 27, 2012, 9:14:35 AM12/27/12
to dotnetar...@googlegroups.com
"A questão não é deixar o modelo de negocio igual ao relacional, a questão é: até que ponto é valido criar a entidade de relacionamento para distribuir uma informação que pode pertencer as duas entidades ou simplesmente criar a propriedade nas duas entidades?"

Então, sobre essa questão... eu entendi que você QUERIA uma entidade que guardasse dados sobre relacionamentos, perdão se entendi errado.

Concordo com o Yokoyama... cara, sua entidade precisa ter as propriedades que ela precisa, seja para guardar ou para trabalhar ela depois. E, como ele falou, existe Lazyload.

Um dado que eu esqueci de citar em outras threads: Ado.Net desconectado é mais rápido do que conectado (SqlDataReader X DataSet), mas EF é mais rápido em alguns casos (mesmo rodando por sima do ado.net desconectado) pois tem o cache de dados e de querys compiladas.
Priscila Mayumi Sato
Líder do .Net Coders e do Windows8Brasil supporter de outras comunidades
Twitter: @MayogaX
image001.jpg

Capetonis

unread,
Dec 27, 2012, 7:02:07 PM12/27/12
to dotnetar...@googlegroups.com
A solução esta na própria resposta. Mas vou repetir: "Pegue o seu relacional e vomite na tela".

Não quis ofender ninguém. É que tem muita gente "fenfível" aqui... Cruzes...
<p class="MsoNo...
Mostrar original

Daniel Moreira Yokoyama

unread,
Dec 27, 2012, 8:19:31 PM12/27/12
to dotnetar...@googlegroups.com
Eu não sei se me sinto mais ofendido com a provocação do "fenfível" ou se com a sugestão de vomitar o relacional na tela.
Somos desenvolvedores, não somos? Vomitar o relacional na tela até o access faz, pq não sugerimos pro amigo usar o lightswitch ou o Maker? Todos eles fazem exatamente isso e poupariam muito tempo (e discussão).
Não, amigo. Somos desenvolvedores. Encaramos um problema e pensamos numa solução pra ele. 
Pior, somos desenvolvedores em uma lista de arquitetura (o que torna essa thread inteira um OFF TOPIC gigantesco, como já me avisaram, mas eu fico tão indignado com a insistência do cara em misturar o relacional com OO que eu não resisto à idéia de tentar fazê-lo entender que uma coisa é uma coisa, e outra coisa é outra coisa... ). mas se é pra dizer que estamos em uma lista de discussão de arquitetura (talvez você não tenha percebido a palavra architects no nome do grupo) então com certeza não estamos aqui para ler uma sugestão porca como a sua. Cuspir o relacional na tela é o mínimo que todo programador deveria saber, então todo mundo já vem aqui com essa resposta como certa, e que se a aceitasse como válida, não tentaria discutir o problema com o grupo.

Vinícius, muita gente, inclusive eu, já tentou dar todo tipo de sugestão. Eu preciso lembrar, até pq fui lembrado por outra pessoa, de que esta thread é um OFF TOPIC e que já foi bem longe (graças inclusive a mim, que fui muito insistente).

Então eu sugiro que ela seja encerrada antes que a sugestão do Capetonis se revele ser apenas o início da escrotidão.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!

--

Bruno Fernandes

unread,
Dec 20, 2012, 11:49:15 AM12/20/12
to dotnetar...@googlegroups.com
meus cents de contribuição:

Por qual motivo vc / sua_equipe modelou sua classe RelacionamentoProdutoClienteInfo com atributos inteiros e não com atributos do tipo ProtudoInfo, e AdquirenteInfo (conforme exemplo abaixo)?

    public class RelacionamentoProdutoClienteInfo

    {

        public ProdutoInfo produto { getset; }

        public AdquirenteInfo adquirente { getset; }

        public decimal codigo_sre { getset; }

    }

 


Att. 

image001.jpg
image002.png

Bruno Fernandes

unread,
Dec 20, 2012, 11:52:37 AM12/20/12
to dotnetar...@googlegroups.com

    public class ProdutoInfo

    {

        public ProdutoInfo()

        {

            listaAdquirentes = new List<RelacionamentoProdutoClienteInfo>();

        }

 

        public Int32 codigo_produto { getset; }

        public string nome_produto { getset; }

        public string numero_conta { getset; }

        public string tipo_produto { getset; }

        public int codigo_empresa { getset; }

        public int codigo_processadora { getset; }

        public string codigo_bin { getset; }

 

        public List<RelacionamentoProdutoClienteInfo> listaAdquirentes { getset; } // O ponto da duvida

    }

 

    public class AdquirenteInfo

    {

        public AdquirenteInfo()

        {

            listaProduto = new List<RelacionamentoProdutoClienteInfo>();

        }

 

        public int codigo_adquirente { getset; }

        public string nome_adquirente { getset; }

        public bool selecionado { getset; }

 

        public List<RelacionamentoProdutoClienteInfo> listaProduto { getset; }  // O ponto da duvida

 

    }

 

    public class RelacionamentoProdutoClienteInfo

    {

        public ProdutoInfo produto { getset; }

        public AdquirenteInfo adquirente { get; set; }

        public decimal codigo_sre { getset; }

    }

 


Att. 




image002.png
image001.jpg

Rafael Ponte

unread,
Dec 20, 2012, 10:57:15 AM12/20/12
to dotnetar...@googlegroups.com
Concordo com o Gerson.

O idioma é muito importante, e é ideal que ele seja universal em todo o projeto (código, documentação, testes, equipe etc). Simplesmente mudar a linguagem de um domínio porque alguém não se sente confortável com o idioma pode trazer problemas na comunicação da equipe.


2012/12/20 Gerson Dias <gerson....@gmail.com>
@Daniel: hmmm.... tenho que discordar.... o domínio é a representação de uma realidade e a realidade é a representação do modelo mental que reflete determinado aspecto que é observado no mundo. Estes aspectos são modificados por questões culturais e linguísticas. Imaginemos que façamos um modelo para um objeto onde as pessoas podem entrar e este objeto irá acelerar e começará a voar. Se estivermos falando da nossa cultura, que já tem todos os conceitos vindos da aviação, o negócio e eu saberei que aquilo é um avião e posso chamá-lo assim. Se estivermos em uma cultura alienígena, aquilo pode se chamar "disco voador", se estivermos numa cultura indígena, aquilo pode ser o "pássaro de ferro". Entende, um conceito pode ser expressado de diversas formas, dependendo da cultura ou da lingua daquele que esta te passando o conhecimento. Infelizmente (ou felizmente) semânticas não são idênticas em diferentes linguas.... haja visto o conceito de valor (value) que é diferente no ingles e no portugues, ou aquele lugar comum da "saudade" que é diferente do "i miss you" dos ingleses.

(peço alguma licença para os exemplos forçados que eu descrevi! hehehehe).

Mas enfim, tema para um novo tópico. 



Att,

 

Thiago C. Santos

 


Att,

 

Thiago C. Santos

 


Att,

 

Thiago C. Santos

 


Att,

 

Thiago C. Santos

 

Foi criado um modelo que represente produto, ondem umas das propriedade é a lista de cliente, e foi criada um modelo cliente onde umas das propriedades é uma lista de produtos.

 

E em ambos um modelo, foi definido uma propriedade que é o modelo da tabela de relacionamento, para que se possa armazenar o código entre produto e cliente.

 

Ao meu ver, tabela de relacionamento não tem sua representação em modelagem e a informação que é exclusiva na tabela de relacionamento tem que existir nos modelos que a utilizem, ou seja, não se deve criar um modelo exclusivo do relacionamento.

 

E o ponto da discórdia é, deve-se existir a sua representação nos modelos de persistência, ou as suas informações tem que se manipuladas com as entidades que a utilizem?

 

O conceito de persistência seria de 1 para 1 ou no caso de entidades de relacionamento as suas relações que devem manipular as informações?

 

Grato pela colaboração,

 

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

--

image001.jpg

Priscila Mayumi Sato

unread,
Dec 28, 2012, 7:26:29 AM12/28/12
to dotnetar...@googlegroups.com
Concordo com o Rafael que concorda com o Gerson :p

Sobre a dúvida... desconfio que é teimosia continuar a usar a RelacionamentoProdutoClienteInfo  pq não estou mais vendo sentido guardar dados do relacionamento. Parece só que você quer ter no modelo a representaçao do relacional, e não ao contrário.

Sugiro, como Yokoyama já disse, centrar no seu modelo e esquecer o relacional, teu ORM (comece a usar um, cara) cuida do resto, vc não vai precisar de uma classe para representar a tabela de relacionamentos.

Pronto, acho que com isso já foi dito tudo o que era preciso, só estamos prolongando uma discussão OFF com os mesmos argumentos.
image001.jpg

Juan Lopes

unread,
Dec 28, 2012, 9:02:12 AM12/28/12
to dotnetar...@googlegroups.com
Se na relação entre produto e cliente existe informação, provavelmente ela não é somente uma relação. Tente dar um nome do domínio (e.g. Compra) para ela e ver se ela lhe parece mais amigável.

2012/12/19 Vinicius Nunes Macedo <viniciu...@bicbanco.com.br>



--
https://github.com/juanplopes
image001.jpg

Capetonis

unread,
Dec 28, 2012, 1:10:25 PM12/28/12
to dotnetar...@googlegroups.com
Cara, entenda como quiser... Acha que estou ofendendo, na realidade estou sendo prático... Deixe de "mimimi".

Para a realidade do cidadão aí (onde ele NÃO pôde nem sequer definir os esquemas do banco, e pior, representou em classes o modelo relacional dele), a melhor sugestão (que eu tenho pra ele) é essa!  

Mas se você prefere tentar convencer ele escrever test first, baby steps, a modelar as classes dele com estado e comportamento direitinho, seguindo os princípios S.O.L.I.D em um cenário onde parece não ser o caso. Fique à vontade... Não sou tão "fenfível" (sem ofensas) a ponto de achar que só a minha opinião vale. Foi só uma sugestão. Não achou válida? Sem problemas. Aceito as críticas e sugestões melhores (e por que não piores) do jeito que elas vierem.

E não. Não sou Arquiteto.

 

"E a pergunta é simples, como fazer para que a propriedade não se repita no conceito de negocio, pois na modelagem de bd, isso é resolvido com a tb de relacionamento, na modelagem d...
Show original

Daniel Moreira Yokoyama

unread,
Dec 28, 2012, 1:48:55 PM12/28/12
to dotnetar...@googlegroups.com
A questão não é ser ou não ser arquiteto, amigo. É que o propósito do grupo é discutir arquitetura (e design que acaba sendo implicitamente envolvido). Não é mimimi... é o propósito do grupo. Se o propósito do grupo não for importante, a existência dele tb deixa de ser.

Atenciosamente,

Daniel Moreira Yokoyama.
@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)
 


Stay Sharp!


--

Capetonis

unread,
Dec 28, 2012, 2:00:44 PM12/28/12
to dotnetar...@googlegroups.com
Ok.

Vinicius Nunes Macedo

<span style="font-size:8.0pt;font-family:"Arial"...
Show original

luis henrique von mecheln

unread,
Jan 7, 2013, 8:25:51 AM1/7/13
to dotnetar...@googlegroups.com
Eu poderia criar uma classe adicional para cada entidade com a propriedade e ter uma herança, com isso eu eliminaria a duplicidade, porem creio ser muito trabalho para um resultado simples.

Vinicius, uma coisa que você não deve fazer é criar uma classe com sua propriedade e fazer herança dela nas classes cliente e produto. Por que está duas classes não são da mesma família e fazer herança apenas para receber uma propriedade não é o correto.





Em quarta-feira, 19 de dezembro de 2012 16h10min10s UTC-2, Vinicius Nunes Macedo escreveu:

Rafael, obrigado pelo retorno.

 

Porem, no caso da criação da entidade e atribui-las na entidade cliente e produto, eu passo a ter a propriedade duplicada.

 

Por exemplo:

 

Produto com List<Cliente>, tenho a propriedade por cliente, mais no produto. E vice-versa também.

 

Eu poderia criar uma classe adicional para cada entidade com a propriedade e ter uma herança, com isso eu eliminaria a duplicidade, porem creio ser muito trabalho para um resultado simples.

 

Não deve haver uma maneira mais elegante de disponibilizar essa propriedade para ambos os lados?

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de Rafael Ponte


Enviada em: quarta-feira, 19 de dezembro de 2012 15:49

Para: dotnetar...@googlegroups.com
Assunto: Re: [dotnetarchitects] Definição de modelagem BD X Modelo de persistencia

 

Ola,

Normalmente quando a tabela de relacionamento faz mais do que relacionar tabelas, ou seja, ela possui estado, há grandes chances de ela ser uma entidade no seu dominio.

Para o seu caso, poderiamos considerar uma entidade Item, na qual teria um relacionamento entre Produto e Cliente mais algumas propriedades que reflitam o estado de Item.

On Dec 19, 2012 1:57 PM, "Vinicius Nunes Macedo" <viniciu...@bicbanco.com.br> wrote:

Sres. do grupo, boa tarde.

 

Estive hoje com um colega de trabalho discutindo sobre a melhor forma de desenhar um modelo de persistência baseado na tabela, e houve algumas discussões e gostaria de expor para vocês para ver qual seria a melhor abordagem para se definir o padrão para persistência.

 

Existe a seguinte estrutura

 

[tabela produto] ß [tabela relacionamento] à tabela cliente

 

Na tabela de relacionamento existe um campo além das chaves que é um valor único (sem ser o ID) para gerar um código único entre cliente e produto. Essa informação é usada tanto para produto, como para cliente.

 

Agora vem o ponto de discussão

 

Foi criado um modelo que represente produto, ondem umas das propriedade é a lista de cliente, e foi criada um modelo cliente onde umas das propriedades é uma lista de produtos.

 

E em ambos um modelo, foi definido uma propriedade que é o modelo da tabela de relacionamento, para que se possa armazenar o código entre produto e cliente.

 

Ao meu ver, tabela de relacionamento não tem sua representação em modelagem e a informação que é exclusiva na tabela de relacionamento tem que existir nos modelos que a utilizem, ou seja, não se deve criar um modelo exclusivo do relacionamento.

 

E o ponto da discórdia é, deve-se existir a sua representação nos modelos de persistência, ou as suas informações tem que se manipuladas com as entidades que a utilizem?

 

O conceito de persistência seria de 1 para 1 ou no caso de entidades de relacionamento as suas relações que devem manipular as informações?

 

Grato pela colaboração,

 

 

 

Descrição: Descrição: cid:image001.jpg@01CC4AB4.B12CBE50

Vinicius Nunes Macedo

Microsoft MCT,MCPD, MCTS, MCP e TTT

Gerencia Desenvolvimento Sistemas V

(11) 2173-9572 – (11) 98581-1233

viniciu...@bicbanco.com.br

www.bicbanco.com.br

 

 

--

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

Reply all
Reply to author
Forward
0 new messages