C# 和 .NET 的“最佳”数据访问框架/方法是什么？

（编辑：我将其设为社区维基，因为它更适合协作格式。）

有多种方法可以从 .NET 访问 SQL Server 和其他数据库。一切都有其优点和缺点，这永远不会是一个简单的问题，哪个是“最好的” - 答案永远是“这取决于”。

然而，我正在寻找在不同级别的系统背景下对不同方法和框架进行高层次比较。例如，我想象对于一个快速而肮脏的 Web 2.0 应用程序，答案将与内部企业级 CRUD 应用程序非常不同。

我知道 Stack Overflow 上有很多涉及这个问题子集的问题，但我认为尝试建立一个总结比较是有用的。我将尽力通过更正和澄清来更新问题。

到目前为止，这是我的高层次理解 - 但我确信这是错误的...... 我主要关注 Microsoft 保持这一重点的方法。

ADO.NET 实体框架 http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework

• 与数据库无关
• 很好，因为它允许交换后端
• 不好，因为它会影响性能并且数据库供应商对此不太满意
• 似乎是MS未来的首选路线
• 学习起来很复杂（尽管如此，请参阅267357 https://stackoverflow.com/questions/267357/how-is-the-net-entity-framework-overkill-versus-linqtosql)
• 它是通过以下方式访问的实体的 LINQ http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework#LINQ_to_Entitiesso 提供了 ORM，从而允许在代码中进行抽象

LINQ 到 SQL http://en.wikipedia.org/wiki/Language_Integrated_Query#LINQ_to_SQL

• 不确定的未来（参见LINQ to SQL 真的死了吗？ http://www.infoq.com/news/2008/11/DLINQ-Future)
• 简单易学 （？）
• 仅适用于 MS SQL Server
• 也可以看看LINQ 的优点和缺点 https://stackoverflow.com/questions/271384/pros-and-cons-of-linq-language-integrated-query

“标准”ADO.NET

• No ORM
• 没有抽象，因此您可以“自己动手”并使用动态生成的 SQL
• 直接访问，可以实现更好的性能
• 这与关于是否关注对象或关系数据的古老争论有关，答案当然是“这取决于大部分工作在哪里”，因为这是一个无法回答的问题，希望我们不会必须深入探讨这一点。恕我直言，如果您的应用程序主要操作大量数据，那么将其过多抽象为前端代码中的对象是没有意义的，您最好使用存储过程和动态 SQL 来完成尽可能多的工作可能在后端。然而，如果您主要进行导致数十或数百行级别的数据库交互的用户交互，那么 ORM 就完全有意义了。因此，我想我对老式 ADO.NET 的看法是在操作和修改大型数据集的情况下，在这种情况下，您将受益于对后端的直接访问。
• 当然，另一种情况是您必须访问已由存储过程保护的旧数据库。

ASP.NET 数据源控件

这些是完全不同的东西还是只是标准 ADO.NET 的一层？ - 如果您有 DAL 或者实现了 LINQ 或实体，您真的会使用这些吗？

NHibernate

• 看起来是一个很厉害很强大的ORM？
• 开源

其他一些相关链接；NHibernate 或 LINQ to SQL https://stackoverflow.com/questions/53417/nhibernate-or-linq-to-sql 实体框架与 LINQ to SQL https://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sql

我认为 LINQ to SQL 非常适合针对 SQL Server 的项目。

如果我们针对不同的数据库，ADO.NET 实体框架会更好。目前我认为很多提供程序可用于 ADO.NET 实体框架、PostgreSQL、MySQL、esql、Oracle 等许多提供程序（检查http://blogs.msdn.com/adonet/default.aspx http://blogs.msdn.com/adonet/default.aspx).

我不想再使用标准 ADO.NET，因为这是浪费时间。我总是选择 ORM。