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 |
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
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?
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.
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?
| Vinicius Nunes Macedo Microsoft MCT,MCPD, MCTS, MCP e TTT Gerencia Desenvolvimento Sistemas V (11) 2173-9572 – (11) 98581-1233 |
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 |
--
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.
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.
É 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.
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?
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.
Mais se eu referenciar a entidade do relacionamento na entidade que precisa da informação ela será duplicada da mesma maneira.
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.
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.
Então Gerson, no contexto eu preciso das duas visões, ai que rolou o dilema da propriedade.
| Vinicius Nunes Macedo Microsoft MCT,MCPD, MCTS, MCP e TTT Gerencia Desenvolvimento Sistemas V (11) 2173-9572 – (11) 98581-1233 |
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?
--
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.
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
Isso
Exatamente, como vcs pediram o contexto real, eu enviei, produto x cliente era só exemplo, então esse vcs esquecem.
Ubiquitous Language
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; }
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?
...
[Mensagem cortada]
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.
--
D (cartão) e VSS_ADQT(
Thiago,
Ate poderia mais com isso eu teria a propriedade duplicada de qualquer maneira. Uma na entidade e outra na lista
| Vinicius Nunes Macedo Microsoft MCT,MCPD, MCTS, MCP e TTT Gerencia Desenvolvimento Sistemas V (11) 2173-9572 – (11) 98581-1233 |
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?
--
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ê.
| Vinicius Nunes Macedo Microsoft MCT,MCPD, MCTS, MCP e TTT Gerencia Desenvolvimento Sistemas V (11) 2173-9572 – (11) 98581-1233 |
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
public class RelacionamentoProdutoClienteInfo
{
public int codigo_produto { get; set; }
public int codigo_adquirente { get; set; }
public decimal codigo_sre { get; set; }
}
poderia ser:
public class RelacionamentoProdutoClienteInfo
{
public ProdutoInfo produtoInfo { get; set; }
public AdquirenteInfo adquirenteInfo { get; set; }
public decimal codigo_sre { get; set; }
}
...
[Message clipped]
Att,Thiago C. Santos
<p class="MsoNormal" style="text-...
Mostrar original
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?
| Vinicius Nunes Macedo Microsoft MCT,MCPD, MCTS, MCP e TTT Gerencia Desenvolvimento Sistemas V (11) 2173-9572 – (11) 98581-1233 |
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 |
--
<p class="MsoNo...
Mostrar original
--
public class RelacionamentoProdutoClienteInfo
{
public ProdutoInfo produto { get; set; }
public AdquirenteInfo adquirente { get; set; }
public decimal codigo_sre { get; set; }
}
public class ProdutoInfo
{
public ProdutoInfo()
{
listaAdquirentes = new List<RelacionamentoProdutoClienteInfo>();
}
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<RelacionamentoProdutoClienteInfo> listaAdquirentes { get; set; } // O ponto da duvida
}
public class AdquirenteInfo
{
public AdquirenteInfo()
{
listaProduto = new List<RelacionamentoProdutoClienteInfo>();
}
public int codigo_adquirente { get; set; }
public string nome_adquirente { get; set; }
public bool selecionado { get; set; }
public List<RelacionamentoProdutoClienteInfo> listaProduto { get; set; } // O ponto da duvida
}
public class RelacionamentoProdutoClienteInfo
{
public ProdutoInfo produto { get; set; }
@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,
Vinicius Nunes Macedo
Microsoft MCT,MCPD, MCTS, MCP e TTT
Gerencia Desenvolvimento Sistemas V
(11) 2173-9572 – (11) 98581-1233
--
"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
--
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.
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?
Vinicius Nunes Macedo
Microsoft MCT,MCPD, MCTS, MCP e TTT
Gerencia Desenvolvimento Sistemas V
(11) 2173-9572 – (11) 98581-1233
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,
Vinicius Nunes Macedo
Microsoft MCT,MCPD, MCTS, MCP e TTT
Gerencia Desenvolvimento Sistemas V
(11) 2173-9572 – (11) 98581-1233
--
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