none
Camada de Banco de Dados - Persistência - Mapeamento Objeto Relacional. RRS feed

  • Pergunta

  • Olá.
    Meu conhecimento do framework .NET é intermediário, mas ainda estou com dúvida de qual tecnologia devo adotar e quais os benefícios e desvantagens de utilizar cada uma delas, ainda mais porque o framework .NET evoluiu muito neste sentido.
    Gostaria de um auxílio de alguém que esteja atualizado para prestar um breve comentário de cada uma das seguintes tecnologias, por obséquio:
    1. LINQ
    2. ENTITY
    3. ADO.NET
    4. DATASET
    5. NHIBERNATE
    Adianto que não é preciso entrar em detalhes de camada de banco de dados, persistência e nem mapeamento objeto relacional, por se tratarem de assuntos bastante difundidos na internet.
    Agradeço desde já e desejo um abraço a todos!
    Gustavo


    segunda-feira, 19 de janeiro de 2009 13:42

Respostas

  • Olá Gustavo,

    Comentário rápido sobre as tecnologias que você mencionou:
    1. LINQ
      Se você está querendo dizer LINQ to SQL (ORM), então o Ricardo Oneda já trouxe uma opinião muito válida. Parece que o L2S vai receber menos investimento que o EF, então eu ficaria longe dele, pelo menos por enquanto.
      O LINQ em si é uma linquagem de queries, e funciona com Datasets, objetos, REST, EF, NH, entre outros. É muito interessante, e sugiro sua utilização fortemente.
    2. Entity Framework (EF)
      ORM feito pela Microsoft, ainda na primeira versão. Sem dúvida a melhor opção no Stack Microsoft para trabalhar com entidades. Melhor que o L2S, dataset, etc.
    3. ADO.Net
      Tecnologia de baixo nível de acesso a dados. L2S, NH, EF, Dataset, todos estes usam ADO.net para se contectar com o banco de dados.
    4. Dataset/Data Adapter/Table Adapter/Command, etc
      Maneira mais trabalhosa de se conectar em um banco de dados. Tudo feito na mão. É o mais eficiente, com menos overhead e mais trabalho para manter, e portanto o mais caro de todos.
    5. NHibernate
      Tecnologia Open Source de ORM. Na minha opinião é a mais madura até o momento, já estando por aí a uns 5 anos mais ou menos. Extremamente flexível. O único problema é a falta de um designer visual para configurar o relacionamento das entidades com o banco, o que te obriga a usar um XML meio chatinho, mas depois disso, fica tudo muito lindo. Ainda por cima, dos ORMs da lista é o único que suporta POCOs na versão atual. O EF vai suportar na versão 2, mas ainda não suporta.
    Se você utilizar uma abordagem como o DDD, o código de acesso aos dados provavelmente vai ficar dentro de um repositório. Pouco da linguagem de query (seja HQL - NH, IQueryable - L2S ou L2E) deve "vazar" para o resto da aplicação, o que garante a troca da tecnologia de acesso a dados com pouco ou nenhum impacto sobre o resto da aplicação.
    Sugiro que você faça um teste com todas, para ver com qual se sente mais a vontade. O EF te dá um excelente ganho na modelagem, porque tem um designer visual, mas tem problemas na testabilidade, e em alguns contextos de SOA, onde a anexação e desanexação do contexto dá trabalho. Isso por não suportar POCOs. Já o NH não tem esse problema, mas tem o XML complicado. Dependendo da complexidade da aplicação, eu não utilizaria EF, pelos problemas citados, e pelo NH estar bem mais maduro.

    Um abraço,

    Giovanni Bassi
    http://unplugged.giggio.net
    terça-feira, 20 de janeiro de 2009 16:03

Todas as Respostas

  • Gustavo, você tocou em um ponto difícil de falar, pois poderá neste post encontrar várias opniões diferentes sobre oq utilizar devido a cada projeto ter sua particularidade, acredito que a tecnologia que deva utilizar é a mais simples e funcional para seu projeto...

     

     

    Procure neste fórum sobre mapeamento relacional e sua diferenças, já existem vários posts que falam sobre estas tecnologias e suas caracteristicas, assim você mesmo poderá tirar suas conclusões.

     

    segue um exemplo.

     

    http://forums.microsoft.com/msdn-br/showpost.aspx?postid=1809948&siteid=21

     

     

    Att

     

    segunda-feira, 19 de janeiro de 2009 22:42
  • Olá Gustavo,

    Comentário rápido sobre as tecnologias que você mencionou:
    1. LINQ
      Se você está querendo dizer LINQ to SQL (ORM), então o Ricardo Oneda já trouxe uma opinião muito válida. Parece que o L2S vai receber menos investimento que o EF, então eu ficaria longe dele, pelo menos por enquanto.
      O LINQ em si é uma linquagem de queries, e funciona com Datasets, objetos, REST, EF, NH, entre outros. É muito interessante, e sugiro sua utilização fortemente.
    2. Entity Framework (EF)
      ORM feito pela Microsoft, ainda na primeira versão. Sem dúvida a melhor opção no Stack Microsoft para trabalhar com entidades. Melhor que o L2S, dataset, etc.
    3. ADO.Net
      Tecnologia de baixo nível de acesso a dados. L2S, NH, EF, Dataset, todos estes usam ADO.net para se contectar com o banco de dados.
    4. Dataset/Data Adapter/Table Adapter/Command, etc
      Maneira mais trabalhosa de se conectar em um banco de dados. Tudo feito na mão. É o mais eficiente, com menos overhead e mais trabalho para manter, e portanto o mais caro de todos.
    5. NHibernate
      Tecnologia Open Source de ORM. Na minha opinião é a mais madura até o momento, já estando por aí a uns 5 anos mais ou menos. Extremamente flexível. O único problema é a falta de um designer visual para configurar o relacionamento das entidades com o banco, o que te obriga a usar um XML meio chatinho, mas depois disso, fica tudo muito lindo. Ainda por cima, dos ORMs da lista é o único que suporta POCOs na versão atual. O EF vai suportar na versão 2, mas ainda não suporta.
    Se você utilizar uma abordagem como o DDD, o código de acesso aos dados provavelmente vai ficar dentro de um repositório. Pouco da linguagem de query (seja HQL - NH, IQueryable - L2S ou L2E) deve "vazar" para o resto da aplicação, o que garante a troca da tecnologia de acesso a dados com pouco ou nenhum impacto sobre o resto da aplicação.
    Sugiro que você faça um teste com todas, para ver com qual se sente mais a vontade. O EF te dá um excelente ganho na modelagem, porque tem um designer visual, mas tem problemas na testabilidade, e em alguns contextos de SOA, onde a anexação e desanexação do contexto dá trabalho. Isso por não suportar POCOs. Já o NH não tem esse problema, mas tem o XML complicado. Dependendo da complexidade da aplicação, eu não utilizaria EF, pelos problemas citados, e pelo NH estar bem mais maduro.

    Um abraço,

    Giovanni Bassi
    http://unplugged.giggio.net
    terça-feira, 20 de janeiro de 2009 16:03