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

Question

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

从.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

Answer 1

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

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

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