As melhores práticas atuais da Microsoft para criar uma camada de dados .NET? E realidade?

A equipe de desenvolvimento com a qual estou trabalhando mudará para o .NET 4.0 em breve; no entanto, a biblioteca de classes de acesso a dados que usamos ainda usa o ADO.NET "classic", significando SqlDataReader , DataTable e similares. Enquanto isso, parece que a Microsoft e provavelmente o resto do mundo estão avançando com o Entity Framework e o WCF Data Services . Não encontrei nada no MSDN que indicasse quais das tecnologias de acesso a dados que a Microsoft considera melhores práticas.

A Microsoft tem uma preferência? Que acesso de dados a maioria das pessoas está usando atualmente? Existem boas razões para permanecer no ADO.NET classic e não mudar para o Entity Framework?

Na minha empresa, estamos usando a EF. É um ORM legal, adequado para nosso pequeno projeto. Na realidade, as pessoas estão usando EF ou NHibernate. Ambas as estruturas são boas. A EF possui um ótimo suporte para MS e você pode encontrar ótimas ferramentas incluídas no Visual Studio. O NHibernate é considerado melhor que o EF, mas há uma "curva de aprendizado" maior, portanto você gastará mais tempo adotando-o.

Eu acho que, se você está no "clássico" do Ado.Net, tente a EF. Crie um projeto simples e substitua alguns dos métodos DAL. Verifique como ele funciona e como você pode gerenciar / modificar o código. Compare-o com os métodos simples "SqlDataReader" e decida qual é o melhor. Lembre-se de que toda mudança de tecnologia precisa de algum tempo para adoção, portanto, é necessário calcular se essa mudança será benéfica para sua empresa a longo prazo.

Minha equipe está achando a realidade de mudar para a EF um pouco difícil. Não é porque o EF seja ruim ou não seja útil, mas o escopo de converter nossas camadas de dados existentes (bastante massivas) de conjuntos de dados fortemente tipificados originários do ADO.Net framework 2.0 para o EF é apenas um trabalho intensivo que realmente não ganha. nos qualquer coisa. Para coisas novas, ainda estamos bastante divididos, porque todos temos opiniões e objetivos. Para nossos projetos Silverlight, estamos focando apenas nos serviços EF e RIA, mas para projetos web (webforms e MVC 3), estamos usando o Linq2Sql principalmente.

Estamos encontrando menos dores de cabeça e um desenvolvimento mais rápido usando o Linq2Sql, mas sei que a Microsoft está promovendo a agenda da EF (principalmente nos serviços WCF e RIA). O Linq2Sql não vai a lugar nenhum, mas todos os novos brinquedos e recursos interessantes serão focados no EF. Eu diria que se você tiver uma escolha desde o início, a EF seria um bom lugar para começar. Se você já está no meio do caminho, não sei se será muito fácil mudar.

O Entity Framework é o caminho preferido. O LinqToSql será suportado e mantido, mas o foco do desenvolvimento daqui para frente está no Entity Framework. Escolhendo entre o ADO.NET Entity Framework e o LINQ to SQL