Microsoft当前建立.NET数据层的最佳做法？和现实？

我正在使用的开发团队将很快迁移到.NET 4.0，但是，我们使用的数据访问类库仍然使用ADO.NET“经典”，即SqlDataReader，DataTable等。同时，Microsoft和世界其他地方似乎都在通过Entity Framework和WCF Data Services向前发展。我没有在MSDN上找到任何表明Microsoft认为最佳实践的数据访问技术的信息。

微软有偏好吗？大多数人当前使用什么数据访问方式？是否有充分的理由使用ADO.NET classic而不迁移到Entity Framework？

在我的公司中，我们正在使用EF。这是一个不错的ORM，适合我们的小型项目。实际上，人们正在使用EF或NHibernate。两个框架都很好。EF拥有强大的MS支持，您可以找到与Visual Studio捆绑在一起的出色工具。NHibernate被认为比EF更好，但是“学习曲线”更大，因此您将花费更多的时间来采用它。

我认为，如果您使用的是Ado.Net“经典”，请尝试EF。创建一个简单的项目并替换一些DAL方法。检查它的工作方式以及如何管理/修改代码。将其与简单的“ SqlDataReader”方法进行比较，然后确定哪个更好。请记住，每次技术变更都需要花费一些时间才能采用，因此从长远来看，您必须计算出这种变更是否对您的公司有利。

我的团队发现迁移到EF的现实有些痛苦。不是因为EF不好或没有用，而是将我们现有的数据层（相当大）从ADO.Net Framework 2.0起源的强类型数据集转换到EF的范围只是大量的工作，实际上并没有收获我们什么。对于新事物，我们仍然很痛苦，因为我们都有自己的见解和目标。对于我们的Silverlight项目，我们仅专注于EF和RIA服务，但是对于Web项目（webforms和MVC 3），我们主要使用Linq2Sql。

我们发现使用Linq2Sql可以减少头痛，并且可以加快开发速度，但是我知道Microsoft一直在推动EF议程（尤其是WCF和RIA服务）。Linq2Sql不会一anywhere而就，但所有新玩具和炫酷功能都将集中在EF上。我想说，如果您有选择的余地，EF将是一个不错的起点。如果您已经中途了，我不知道切换起来会很容易。

首选实体框架。LinqToSql将得到支持和维护，但是未来的开发重点是实体框架。在ADO.NET实体框架和LINQ to SQL之间进行选择