none
Divisão das camadas e consultas complexas? RRS feed

  • Pergunta

  • Caros amigos do Grupo

    Uma dúvida recorrente quando se fala em orientação a objeto é sem dúvida sua relação com banco de dados. Deste modo, gostaria da opinião de vocês sobre a melhor arquitetura para um software orientado a objeto utilizando banco de dados relacional.

    Sendo mais específico, digamos que eu tenha um banco de dados na 3ª forma normal, onde uma consulta simples terá que ser baseada em 5 ou 6 tabelas, supondo que eu estou utilizando um modelo APL > BL > DAO e tenho um mapeamento das tabelas realizado, onde cada objeto/ tabela esta mapeado com base no famoso mapeamento objeto-relacional. Qual seria a forma mais inteligente de trazer estas informações conjuntas para um Grid, ou mesmo um relatório?

    Na forma procedural, enviaríamos uma consulta ao BD fazendo todos os “joins” necessários, e pronto! Retorna um Datatable que vai carregar os dados na apresentação.

    Mas como nem tudo são flores, qual seria a melhor maneira em um projeto OO? Mantendo o enfoque no tão sonhado “baixo acoplamento e alta coesão” J

    - Lembrando que alterar o banco de dados não é uma opção, pois trata-se de uma aplicativo já desenvolvido.

    - As consultas podem variar quanto ao seu retorno, logo,  também não seria uma boa alternativa a criação de views.

    Abraço a todos,

    Edson

    domingo, 27 de maio de 2012 18:01

Respostas



  • Olá Edson,
    Tudo beleza?

    Tecnicamente não existe uma melhor arquitetura para um projeto OO. Na verdade existe um conjunto de padrões que são aqueles mais utilizados. Padrões como MVC, DAL, MVVM, MVP são orientados a objetos e são bastante eficientes. Tudo depende do seu projeto.

    Acredito que a combinação MVA + DAL é uma boa solução. Quase sempre se adapta a maioria dos projetos.

    Não necessariamente a abordagem que vc utilizar vai exigir modificações na base de dados. Utilizando Entity Framework ou ADO.Net vc irá conseguir atingir seus objetivos facilmente.

    Existe algum motivo para não utilizar Views? Acredito que consultas cujos resultados variam devem ter Views específicas para aqueles contexto. Não vejo problemas em utilizar Views, tudo depende do modo como vc programa sua aplicação. Vc tem algum cenário que não gostaria de atingir?

    Com relação ao baixo acoplamento, neste caso o uso de interfaces é indicado, pois vc acaba não dependendo de um tipo concreto. Técnicas de injeção de dependências são legais, talvez vc queira ler algo sobre isso.

    Aqui existem exemplos de aplicações Orientadas a Objetos utilizando MVC:
    - http://ferhenriquef.com/2011/10/25/entity-framework-4-1-mvc-dao/
    - http://ferhenriquef.com/2009/09/27/mvc-dao-db4o/
    - http://ferhenriquef.com/2011/11/26/construindo-sua-camada-de-acesso-a-dados-com-o-entity-framework-4-1/

    Qualquer dúvida que tiver vamos discutindo :)

    []s!


    Fernando Henrique Inocêncio Borba Ferreira
    while(alive){ this.WriteCode(); }
    Blog: http://ferhenriquef.com/
    Twitter: @ferhenrique

    • Marcado como Resposta Harley Araujo terça-feira, 29 de maio de 2012 12:58
    segunda-feira, 28 de maio de 2012 13:36

Todas as Respostas



  • Olá Edson,
    Tudo beleza?

    Tecnicamente não existe uma melhor arquitetura para um projeto OO. Na verdade existe um conjunto de padrões que são aqueles mais utilizados. Padrões como MVC, DAL, MVVM, MVP são orientados a objetos e são bastante eficientes. Tudo depende do seu projeto.

    Acredito que a combinação MVA + DAL é uma boa solução. Quase sempre se adapta a maioria dos projetos.

    Não necessariamente a abordagem que vc utilizar vai exigir modificações na base de dados. Utilizando Entity Framework ou ADO.Net vc irá conseguir atingir seus objetivos facilmente.

    Existe algum motivo para não utilizar Views? Acredito que consultas cujos resultados variam devem ter Views específicas para aqueles contexto. Não vejo problemas em utilizar Views, tudo depende do modo como vc programa sua aplicação. Vc tem algum cenário que não gostaria de atingir?

    Com relação ao baixo acoplamento, neste caso o uso de interfaces é indicado, pois vc acaba não dependendo de um tipo concreto. Técnicas de injeção de dependências são legais, talvez vc queira ler algo sobre isso.

    Aqui existem exemplos de aplicações Orientadas a Objetos utilizando MVC:
    - http://ferhenriquef.com/2011/10/25/entity-framework-4-1-mvc-dao/
    - http://ferhenriquef.com/2009/09/27/mvc-dao-db4o/
    - http://ferhenriquef.com/2011/11/26/construindo-sua-camada-de-acesso-a-dados-com-o-entity-framework-4-1/

    Qualquer dúvida que tiver vamos discutindo :)

    []s!


    Fernando Henrique Inocêncio Borba Ferreira
    while(alive){ this.WriteCode(); }
    Blog: http://ferhenriquef.com/
    Twitter: @ferhenrique

    • Marcado como Resposta Harley Araujo terça-feira, 29 de maio de 2012 12:58
    segunda-feira, 28 de maio de 2012 13:36

  • Oi Fernando,

    Obrigado pelas dicas. Vou analisar os sites que me indicou e retorno com eventuais dúvidas.

    Com relação à forma de retornar os dados em consultas complexas ainda fiquei com algumas dúvida. Veja bem, digamos que eu precise retornar do BD os dados de um cliente, estes dados estão distribuídos em 6 tabelas distintas e normalizadas. Qual seria o procedimento mais acertado para recuperar estes dados e carregá-los em um Grid?

    O que seria mais apropriado, criar os 6 objetos e um algoritmo que organize este retorno e os carregue no Grid?

    Existe dentro dos modelos que me sugeriu algo que possa minimizar este trabalho, tanto de programação quando de consumo dos recursos no BD, uma vez que a criação dos 6 objetos implicaria invariavelmente em ir 6 vezes ao Baco de dados e retornando separadamente os dados do cliente?

    Apenas para melhor entendimento, faço um  paralelo com o modelo de programação procedural. Neste eu apenas enviaria os comandos SQL contendo os "joins" e "restrições" e pronto. Os dados estariam prontos para inserção no grid, todavia, com pouca ou nenhuma divisão entre camadas...Existe um meio termo (OO/Procedural) ? :-/

    Como você sugere retornar estes dados para a camada de apresentação?

    Abraço,

    Edson


    terça-feira, 29 de maio de 2012 13:56
  • Boa tarde senhores...

    Faço uso desse cenário também, divido meu projeto em 3 camadas:

    • Entidades - Representação de cada tabela do banco.
    • DALS - Inserts, Updates... para cada tabela do banco.
    • BLLs - Lógica de negócio para cada tabela do banco.

    Só para ilustrar, na View (tela de uma dada aplicação) eu crio um objeto do tipo Cliente_ENT e Cliente_BLL, preencho o objeto Cliente_ENT com os dados de um cliente e depois chamo um dado método inserção do objeto Cliente_BLL passando Cliente_ENT como parâmetro, no Cliente_BLL é feita toda a validação, em seguida Cliente_BLL chama uma função de Cliente_DAL que só se encarrega de gravar esse cara no banco.

    Se eu for carregar um cliente chamo um método em Cliente_BLL onde passo como parâmetro o id desse cliente, por sua vez ele chama um método de Cliente_DAL que vai no banco e pega os dados desse cliente, devolve para o Cliente_BLL que por sua vez devolve pra View popular o grid. Enfim, deve ser mais ou menos oque vc faz ai.

    Pensando que pra cada tabela do banco temos ENTIDADE, DAL e BLL como fazer quando, por exemplo, é preciso popular um grid com dados de várias tabelas, eu particularmente uso views, e ai ela entra no meu modelo como uma tabela, com sua respectiva ENTIDADE, DAL e BLL, só não vou ter métodos de gravação pra ela.

    E por vezes também preciso de objetos mais específicos que são constituídos de varias tabelas e não tenho views para eles, faço a mesma coisa, crio a ENTIDADE, DAL e VIEW desses caras e uso normalmente.

    Bom, esse é o jeito que faço, aceito criticas e sugestões ai...

     

    Abraços.


    terça-feira, 12 de junho de 2012 20:29