none
Mapear relacionamento em classes RRS feed

  • Pergunta

  • Olá a todos,

     

    Na empresa onde trabalho estamos criando um novo projeto que utiliza a arquitetura em 3 camadas, porém, como estamos iniciando temos muitas dúvidas. Atualmente nossa principal dificuldade é como vamos realizar os relacionamentos que temos na base de dados nas classes, ou seja, temos uma classe Pessoa e outra classe Endereco, que possui relacionamento 1 x n, como reperentariamos na classe Pessoa, como um vetor? list? Dataset? Inserção de metodos na classe Pessoa para lidar com a de Endereco?

    Qual a melhor sugestão?

    E quando temos relacionamento n x n?

     

    Obrigada.

    quarta-feira, 5 de setembro de 2007 15:04

Respostas

  • Você sempre deve pensar em termos de objetos, não de banco de dados.

     

    No seu exemplo, a classe Pessoa deveria ter uma propriedade chamada Enderecos, do tipo EnderecoCollection. EnderecoCollection, por sua vez, estende List<Endereco> - ou seja, é uma lista genérica de endereços.

     

    No caso de relacionamentos n x n (por exemplo, produtos e fornecedores), a classe Produto teria uma propriedade Fornecedores e a classe Fornecedor teria uma propriedade Produtos, ambas retornando uma coleção. Ou seja, repare que do ponto de vista da orientação a objetos não faz diferença como os relacionamentos estão representados no banco de dados.

    quarta-feira, 5 de setembro de 2007 16:03

Todas as Respostas

  • Você sempre deve pensar em termos de objetos, não de banco de dados.

     

    No seu exemplo, a classe Pessoa deveria ter uma propriedade chamada Enderecos, do tipo EnderecoCollection. EnderecoCollection, por sua vez, estende List<Endereco> - ou seja, é uma lista genérica de endereços.

     

    No caso de relacionamentos n x n (por exemplo, produtos e fornecedores), a classe Produto teria uma propriedade Fornecedores e a classe Fornecedor teria uma propriedade Produtos, ambas retornando uma coleção. Ou seja, repare que do ponto de vista da orientação a objetos não faz diferença como os relacionamentos estão representados no banco de dados.

    quarta-feira, 5 de setembro de 2007 16:03
  • Realmente existem alguns riscos de se pensar do Banco de dados para o modelo de objetos ao invés do contrário.

     

    Este é um exemplo. Se você pensar em termos de negócio, o Endereço é uma entidade representativa? Tem vida própria? Claro que eu preciso dele, claro também que vou persistí-lo no Banco de dados. Mas se você fizer algumas perguntas chegará a conclusão que ele não tem vida própria.

     

    Qual o identificador de um endereço? Pais + Estado + Cidade + Rua + No + Complemento. Estranho, praticamente todo o endereço

     

    Quais operações um endereço tem? .... Não consegui pensar em uma nestes 3 minutos...

     

    Eu modelaria o endereço como Value object, implementado com um struct, em C#. Uma pessoa teria uma coleção de endereços. Nem sei se me daria ao trabalho de criar um EnderecoCollection, talvex escolhesse uma das coleções genéricas já existentes e faria List<Endereco> direto.

     

    Eduardo Miranda

    www.eduardomiranda.net/blogs/dotnet/

     

     

    sexta-feira, 7 de setembro de 2007 10:48
  • Olá Pessoal,

     

    Algumas semanas atrás estavamos validando um diagrama de classes de uma consultoria e deparei-me com o cenário que você apresentou Eduardo.

     

    A escolha da List<Endereco> foi unânime. O mais dificil foi dar um nome para o componente que cuida de tudo isto Pais,Estado,Cidade,Logradouro,MicorRegiao,Comarca,MesoRegiao.. .etc....

     

    A solução foi de separar um componente que cuide só de Localização. Ali armazenamos tudo que compete a responsabilidade de se localizar algo.

     

    Agora todos os outros componentes usam este serviço de localização. 

     

     

    []´s

     

     

     

     

     

    sábado, 8 de setembro de 2007 14:49
  • Saudações,

     

    Ola Ana Paula, o problema que enfrenta não tem uma "resposta fórmula de bolo", afinal esse e um grande paradigma, visto que o Banco é Relacional e o projeto O.O. Para isso tem diversos Patterns e esse assunto e muito discutido. Creio que com o tempo (expêriencia) vc e sua equipe chegarão a uma boa solução.

     

    Sendo que, o mapeamento objeto relacional não seria o unico pattern a ser adotado. O proprio patterns da Microsoft não utiliza o mapeamento objeto relacional, e sim DataSet. Mas ai entra uma outra discussão. Até a versão do framework 1.1 eu dava razão para quem não queria utilizar o Patterns da Microsoft (DataSet, DataAccess, Component, WorkFlow usando o Application blocks), visto que o DataSet para manipular grandes quantidades de dados era ruim.Apesar de que sou contra grandes manipulações de dados do lado do cliente, e que caso seja necessário sempre é possível minimizar esses dados trabalhando do lado do banco e paginando se for o caso. Então desde a versão 1.1 eu abandonei o mapeamento objeto relacional.

     

    Com ao Framework 2.0 e a IDE 2005, nossa o ganho que tenho de tempo e mais de 50% com o uso de DataSet configurando o DataAdapter. Então não volto mesmo para o mapeamento e não vejo motivos para tal.

     

    Não fico restrito em nada com o código gerado automaticamente pelo DataAdapter, pois posso estender o código utilizando Partial. Em questões de manutenção é super rápido, manipulação é otima, construção é rapida, velocidade ótima. A unica questão é interoperabilidade, se vc tiver que expor isso para alguém utilizar em outra linguagem ai sim terá problemas, para os projetos em que participo a grande maioria das vezes quase 90%, não é o caso de expor isso. Quando necessário, não seria para expor também todo o projeto e sim algo bem especifico , dessa forma crio uma outra camada com o mapeamento para tratar essas particularidades.

     

    Então experimenta utilizar dataset, configure o DataAdapter ele tem wizard para isso, pode usar comando SQL ou Store Procedure (Ele já cria a store). E então vc teria o seu Objeto Cliente criado em minutos com os metodos necessários. A questão em si do mapeamento seria mais facil ser resolvida, visto que um DataTable não precisa ser necessariamente igual a Tabela do Banco. Vc monta a estrutura do DataTable de acordo com as consultas SQL.

     

    Abaixo um link que explica o que expus, sendo com exemplo web, mas não tem diferença na camada de acesso a dados para windwos, inclusive vc pode criar somente uma unica camada e utilizar tando para Web como para o Windows no front end

     

    http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=pt-BR&EventID=1032341963&CountryCode=BR

     

    Eu já adoto esse modelo, a parte de transação também já foi resolvida utilizando partial, caso deseje mais informação sobre esse padrão é so postar...

     

     

    segunda-feira, 22 de outubro de 2007 22:49
  • Já fiz uma crítica ao modelo sugerido no webcast em outra discussão deste fórum:

    http://forums.microsoft.com/MSDN-BR/ShowPost.aspx?PostID=1959062&SiteID=21

     

    Eduardo Miranda

    www.eduardomiranda.net/blogs/dotnet/

     

    terça-feira, 23 de outubro de 2007 12:11
  • Eu participei desta discussão e concordo com o Eduardo.
    Acho que essa questão de wizards/datasets, não é o momento. Ainda precisa-se evoluir muito para podermos dedicar a uma "Arquitetura Orientada a Componentes". A manutenção fica muito complexa.

    Pode ser que no futuro, tenhamos algo viável.
    quinta-feira, 8 de novembro de 2007 18:25
  • Olá Pessoal,

     

    Gostaria de agradecer a todos pela atenção.

    Estou vendo as respostas apenas agora, mas achei a discussão muito válida e interessante.

    É sempre bom saber que temos pessoas com mais experência e dispostas a trocar esse tipo de informação.

    Aqui na empresa acabamos utilizando o List como propriedade da classe.

    Mais uma vez, obrigada a todos.

     

     

    sexta-feira, 23 de novembro de 2007 11:02