Les meilleures pratiques actuelles de Microsoft pour la création d'un niveau de données .NET? Et la réalité?

L'équipe de développement avec laquelle je travaille passera bientôt à .NET 4.0, cependant, la bibliothèque de classes d'accès aux données que nous utilisons utilise toujours ADO.NET "classique", c'est-à-dire SqlDataReader , DataTable, etc. Pendant ce temps, il semble que Microsoft et probablement le reste du monde avancent avec Entity Framework et WCF Data Services . Je n'ai rien trouvé sur MSDN qui indiquait laquelle des technologies d'accès aux données Microsoft considère comme les meilleures pratiques.

Microsoft a-t-il une préférence? Quel accès aux données la plupart des gens utilisent-ils actuellement? Y a-t-il de bonnes raisons de rester avec ADO.NET classic et de ne pas passer à Entity Framework?

Dans mon entreprise, nous utilisons l'EF. C'est un joli ORM, adapté à notre petit projet. En réalité, les gens utilisent EF ou NHibernate. Les deux cadres sont bons. EF a un excellent support MS et vous pouvez trouver d'excellents outils fournis avec Visual Studio. NHibernate est considéré comme meilleur que EF mais il y a une plus grande "courbe d'apprentissage" donc vous passerez plus de temps à l'adopter.

Je pense que, si vous êtes sur le "classique" Ado.Net, essayez l'EF. Créez un projet simple et remplacez certaines des méthodes DAL. Vérifiez comment cela fonctionne et comment vous pouvez gérer / modifier le code. Comparez-le avec les méthodes simples "SqlDataReader" et décidez laquelle est la meilleure. N'oubliez pas que chaque changement technologique nécessite un certain temps pour être adopté, vous devez donc calculer si ce changement sera bénéfique à long terme pour votre entreprise.

Mon équipe trouve la réalité de passer à EF un peu pénible. Ce n'est pas parce que EF est mauvais ou pas utile, mais la portée de la conversion de nos couches de données existantes (assez massives) à partir d'ensembles de données fortement typés provenant d'ADO.Net Framework 2.0 vers EF est juste beaucoup de travail intensif qui ne gagne pas vraiment nous quoi que ce soit. Pour les nouveautés, nous sommes encore assez déchirés car nous avons tous des opinions et des objectifs. Pour nos projets Silverlight, nous nous concentrons uniquement sur les services EF et RIA, mais pour les projets Web (formulaires Web et MVC 3), nous utilisons principalement Linq2Sql.

Nous constatons moins de maux de tête et un développement plus rapide en utilisant Linq2Sql, mais je sais que Microsoft pousse l'agenda EF (en particulier avec les services WCF et RIA). Linq2Sql ne va nulle part, mais tous les nouveaux jouets et fonctionnalités intéressantes seront concentrés dans EF. Je dirais que si vous avez le choix au début, EF serait un bon point de départ. Si vous êtes déjà à mi-parcours, je ne sais pas que ce sera très facile de basculer.

Entity Framework est la solution préférée. LinqToSql sera pris en charge et maintenu mais le développement se concentrera à l'avenir sur Entity Framework. Choisir entre ADO.NET Entity Framework et LINQ to SQL