Camada de Banco de Dados - Persistência - Mapeamento Objeto Relacional.
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:
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!
segunda-feira, 19 de janeiro de 2009 13:42
a própria Microsoft está recomendando utilizar o Entity Framework ao invés do LINQ To Sql, veja:
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
http://blogs.msdn.com/adonet/archive/2008/10/31/clarifying-the-message-on-l2s-futures.aspx
http://oneda.mvps.org/blog
terça-feira, 20 de janeiro de 2009 01:04
Comentário rápido sobre as tecnologias que você mencionou:
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.
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.
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.
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.
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.
http://unplugged.giggio.net
terça-feira, 20 de janeiro de 2009 16:03
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.