哪个是C#和.NET的"最佳"数据访问框架/方法？

(编辑:我把它变成了社区维基,因为它更适合协作格式.)

从.NET访问SQL Server和其他数据库有很多种方法.所有这些都有其优点和缺点,它永远不会是一个简单的问题,哪个是"最好的" - 答案永远是"它取决于".

但是,我正在寻找不同层次系统背景下不同方法和框架的高层次比较.例如,我认为对于快速而肮脏的Web 2.0应用程序,答案与内部企业级CRUD应用程序有很大不同.

我知道Stack Overflow上有很多关于这个问题子集的问题,但我认为尝试构建一个汇总比较会很有用.我会尽力更新问题并加以纠正和澄清.

到目前为止,这是我对高层的理解 - 但我确信这是错误的......我主要关注微软的方法来保持这一点.

ADO.NET实体框架

数据库不可知

很好,因为它允许交换后端

糟糕,因为它可以达到性能,数据库供应商对它不太满意

似乎是MS未来的首选路线

复杂学习(但见267357)

它通过LINQ to Entities访问,因此提供ORM,从而允许在代码中进行抽象

LINQ to SQL

不确定的未来(参见LINQ to SQL真的死了吗？)

简单易学 (？)

仅适用于MS SQL Server

另请参见LINQ的优缺点

"标准"ADO.NET

没有ORM

没有抽象,所以你回到"自己动手"并使用动态生成的SQL

直接访问,可以提供更好的性能

这与关于是否专注于对象或关系数据的古老争论有关,答案当然是"它取决于大部分工作的位置",因为这是一个无法回答的问题,希望我们不要不得不太过分了.恕我直言,如果你的应用程序主要是操作大量数据,将它过多地抽象到前端代码中的对象是没有意义的,你最好使用存储过程和动态SQL来完成尽可能多的工作.可能在后端.然而,如果您主要进行用户交互,导致数十或数百行的数据库交互,那么ORM就完全有意义了.所以,我想我对旧式ADO.NET的论证是在你操纵和修改大数据集的情况下,

当然,另一种情况是您必须访问已由存储过程保护的旧数据库.

ASP.NET数据源控件

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

NHibernate的

似乎是一个非常强大和强大的ORM？

开源

其他一些相关链接; NHibernate或LINQ to SQL Entity Framework与LINQ to SQL

我认为LINQ to SQL适用于针对SQL Server的项目.

如果我们针对不同的数据库,ADO.NET实体框架会更好.目前我认为很多提供商可用于ADO.NET实体框架,PostgreSQL,MySQL,esql,Oracle等许多提供商(请访问http://blogs.msdn.com/adonet/default.aspx).

我不想再使用标准的ADO.NET了,因为这是浪费时间.我总是去找ORM.